Independent monitoring for SendGrid Marketing Campaigns and transactional sends
SendGrid makes it easy to build Marketing Campaigns with suppressions, list segments and dynamic templates. Each of those components can also break quietly. SendGrid reports the send as delivered. The customer's inbox is empty.
Telltide confirms what actually arrived, send by send, from the inbox.
The flows that matter
SendGrid sends our customers monitor
SendGrid's email surface stretches across Marketing Campaigns, Automation flows, transactional v3 Mail Send API calls, and legacy v2 API sends. Each surface has its own quiet failure modes.
Marketing Campaigns
Scheduled sends to segmented contact lists. When suppression logic changes, when a list import overwrites active contacts, or when a custom field rename breaks segmentation criteria, the campaign fires to a smaller audience than intended. SendGrid logs the send as successful to whoever qualified.
Automation flows
Triggered on contact list entry, custom field updates, or engagement events. A trigger condition can shift when a contact property is deprecated. The Automation sits idle. SendGrid logs nothing because the trigger condition was never met.
Transactional v3 Mail Send API
Order confirmations, password resets, booking receipts. Often wired up by an engineering team that does not own the SendGrid account day to day. When the API integration breaks, SendGrid returns an error code to the caller. If nobody is watching that log, the customer sees nothing.
Dynamic template sends
Transactional emails built with Handlebars substitution tags. A substitution value is renamed in the application code. The template renders with a blank value. SendGrid logs the send as delivered. The email arrives with broken personalisation.
Suppression group failures
Contacts added to a suppression group should not receive emails in that group. When suppression logic is misconfigured, when a contact is on multiple lists with conflicting suppression states, or when a bulk import overwrites suppression preferences, emails go out to suppressed contacts.
Legacy v2 API sends
Still in use at many organisations. No dynamic template support. Substitution values are passed in the API call. When the caller passes a malformed payload or an empty substitution, SendGrid accepts the request and sends a broken email.
How it goes wrong
Common SendGrid silent-failure patterns
SendGrid rarely throws errors when a send simply does not fire or arrives broken. These are the failure modes we see most often in live accounts.
Suppression list error sends to opted-out contacts
A contact is added to a suppression group via CSV import. The import maps the wrong column to the suppression group field. The contact thinks they opted out. SendGrid thinks they are still active. The next Marketing Campaign fires. The contact receives it.
Dynamic template substitution value missing
A dynamic template references a Handlebars variable for the customer's first name. The application code renames the variable from first_name to given_name. The Mail Send API call still passes first_name. The template renders with a blank value where the name should be. SendGrid logs the send as delivered.
List segment criteria drift excludes cohorts
A Marketing Campaign is built on a segment defined by custom field values. An engineer changes the field type from string to integer. Existing contacts with string values no longer qualify for the segment. The campaign fires to a smaller list. SendGrid reports the send as successful.
Automation trigger condition never evaluates true
An Automation is triggered when a custom field equals a specific value. The field is updated upstream in the CRM. The new value is written in a different case. The trigger condition is case-sensitive. The Automation never fires. SendGrid logs nothing because the condition was not met.
API key rotated without scope update
Engineering rotates a SendGrid API key for security hygiene. The replacement key is missing the mail.send scope. The integration thinks it sent an email. SendGrid logs a 403 error in the Activity Feed. Nobody is watching the Activity Feed for that specific error code.
Duplicate sends from retry logic
A transactional send fails with a timeout error. The application retry logic fires again. SendGrid processes both requests. The customer receives the same email twice. SendGrid logs both as delivered. The duplicate is only visible if you compare message IDs manually.
SendGrid observability vs native analytics
What SendGrid's dashboards show, and what they miss
SendGrid's Activity Feed and Stats dashboard are detailed. They show you every API call, every delivery event, every bounce. What they cannot show you is whether the email that SendGrid logged as delivered actually arrived at the inbox in the shape you intended.
SendGrid reports delivery, not arrival
When SendGrid logs an email as delivered, it means the receiving mail server accepted the message. It does not mean the message reached the inbox. It does not mean the message was not filtered to spam. It does not mean the message rendered correctly. Inbox-side monitoring confirms all three.
Activity Feed shows events, not outcomes
The Activity Feed logs processed, delivered, opened, clicked. It does not log what the customer saw when they opened the email. If a dynamic template substitution failed, the Activity Feed still shows delivered and opened. The customer saw a broken email.
Suppression errors are logged, not alerted
When a send is blocked by a suppression group, SendGrid logs a dropped event in the Activity Feed. It does not alert you that the send was dropped. If the suppression was misconfigured and the contact should have received the email, you will not know until the customer complains.
Duplicate sends are not flagged
When retry logic causes duplicate sends, each send gets its own message ID. The Activity Feed shows two separate delivered events. There is no automatic correlation between them. You have to manually query the Activity Feed by recipient address and time range to spot duplicates.
How Telltide fits
A inbox-side monitor for every SendGrid send
Telltide does not sit inside SendGrid. It runs alongside, watching the inbox for the sends SendGrid says it made.
Add a monitored contact to your SendGrid list
Telltide gives you a unique inbox address per monitor. You create a contact with that address in SendGrid, give it the relevant custom field values or suppression group memberships, and let it receive sends naturally.
Set the expected arrival window
For a transactional v3 Mail Send API call, that might be five minutes. For a Marketing Campaign, one hour. For an Automation with a delay step, 24 hours plus a buffer. Per monitor.
Get alerted when the inbox disagrees with SendGrid
If the email does not arrive in the window, an alert fires. If the content is corrupt against the reference template, an alert fires. If the email arrives twice, an alert fires. The Activity Feed might still report delivered. The alert tells you what is actually arriving at the inbox.
Monitoring specific SendGrid components
Dynamic templates, suppressions and Automation delays
Each SendGrid component has its own monitoring considerations. Here is how to set up a Telltide monitor for the components that break most often.
Send a reference email first, then monitor ongoing sends
Before you set up the monitor, send a test email to the Telltide address with all substitution values populated correctly. That becomes the reference template. Each subsequent send is compared against it. If a substitution value goes missing or renders incorrectly, the monitor alerts on structural deviation.
Add the monitor contact to the suppression group, then remove it
Test the suppression logic by adding the Telltide contact to the group. The next send should not arrive. If it does, the suppression is misconfigured. Remove the contact from the group. The next send should arrive. If it does not, the list logic is broken.
Set the arrival window to match the delay duration
If an Automation includes a 48-hour delay, set the Telltide monitor's expected arrival window to 48 hours plus a 30-minute buffer. The monitor will alert if the email arrives too early, which indicates the delay was skipped, or too late, which indicates the send was queued further downstream.
Watch the first send after segment criteria change
If a Marketing Campaign is built on a segment, and the segment criteria are updated, send a test to the Telltide contact immediately after the change. If the contact no longer qualifies for the segment, the monitor will alert. If it still qualifies but the send is corrupt, the monitor will catch that too.
Transactional sends vs Marketing Campaigns
Different surfaces, different monitoring approaches
SendGrid serves two distinct surfaces. Transactional sends (v3 Mail Send API, legacy v2 API) are high-urgency, low-volume. Marketing Campaigns are lower-urgency, higher-volume. Each needs a different monitoring cadence.
Monitor every send, or use heartbeat cadence
For password resets and order confirmations, set a tight arrival window. Five to ten minutes. Alert immediately if the email does not arrive. For high-volume transactional sends where individual failures are acceptable but complete outages are not, use heartbeat monitoring. Fire a test send every 15 minutes. Alert if three consecutive sends fail.
Monitor scheduled sends and track arrival timing
For a weekly newsletter, set the arrival window to match the scheduled send time plus one hour. If the email does not arrive, it means the campaign did not fire, or the contact was excluded by segment criteria, or suppression logic blocked it. For Automation flows, monitor the first send after a trigger event. Set the window to match the delay step duration.
Pair it with
Concepts and use cases worth reading
The reading below covers the underlying concepts and the practical applications for SendGrid monitoring.
- Monitor by ESP: guides for other platforms if you send from multiple systems.
- Heartbeat monitoring: when to alert on cadence rather than single sends.
- How monitoring approaches compare: where native analytics end and where independent monitoring picks up.
FAQ
Common questions about monitoring SendGrid
Doesn't SendGrid's Activity Feed show me whether emails went out?
SendGrid reports on what its send infrastructure attempted and what it logged as delivered. It cannot confirm what arrived at a real inbox, when, or in what condition. Inbox-side monitoring closes that gap by watching the inbox itself.
What SendGrid sends can I monitor?
Marketing Campaigns, Automation sends, transactional emails sent via the v3 Mail Send API, and dynamic template sends. Anywhere SendGrid dispatches an email, Telltide can confirm whether it arrived.
Do I need to grant SendGrid API access or install a connector?
No. Telltide is independent of your SendGrid account. You add a Telltide monitoring email as a contact in the relevant list or suppression group. We never log into your SendGrid account.
How do I monitor a SendGrid Automation with delay steps?
Create a contact for the Telltide monitoring address. Add it to the list that triggers the Automation. Set the expected arrival window in Telltide to match the delay duration. The monitor confirms each subsequent email step fires as configured.