Status=sending with no recent sends = trigger broken or template-render error after a Mailchimp UI version change.
At a glance
A real-time silent-failure detector for Mailchimp automations (Customer Journeys and Classic Automations). It fires when an automation is still marked as actively sending but has produced no send activity for more than 24 hours. This is the single most expensive silent failure in email marketing, an automation in a sending state looks healthy on the Mailchimp dashboard while quietly delivering nothing, so abandoned-cart recovery, welcome onboarding, and post-purchase follow-ups stop earning revenue with no obvious error. The most common causes are a broken trigger after a Customer Journey version change, a template-render error introduced when a merge tag or product block was edited, or a connected store (Shopify, BigCommerce) whose data feed stopped. The card lists each affected automation so the marketing team knows exactly what to republish.
The alert is the action: every hour a high-revenue automation sits dark is recoverable revenue lost.
| What it counts | The set of automations where the workflow status is sending (actively running) and the timestamp of the last emitted email is older than 24 hours. Each row is one affected automation, with its name, type (Customer Journey or Classic), last-send time, and the audience it serves. |
| Why this matters | A sending status means Mailchimp believes the automation is live, so there is no error banner in the UI. The only signal that something broke is the absence of sends, which is invisible unless you are actively watching send volume per automation. This card watches it for you. |
| Common root causes | (1) A Customer Journey was edited and the trigger step was left disconnected after a UI version migration. (2) A template-render error: an edited merge tag, a deleted product feed block, or a broken dynamic-content rule causes every queued send to fail render. (3) The connected store feed stopped (re-auth needed), so the trigger event (cart abandoned, order placed) never reaches Mailchimp. (4) The serving audience was emptied or its segment condition now matches zero members. |
| What it is not | Not a low-volume warning. An automation that legitimately serves a small audience and sends a few emails a week is fine, the 24-hour window is generous enough that genuinely active low-volume journeys do not trip it. The alert targets the case where a journey that should be firing has gone completely dark. |
| Currency | n/a, this is a count of affected automations. The revenue at stake surfaces in top-automations-by-revenue and abandoned-cart-recovery-value. |
| Time window | RT (real-time). Evaluated each sync cycle against the last-send timestamps; no rolling average, the condition is binary per automation. |
| Alert trigger | Any automation with last_email_sent_at older than 24 hours while status is sending. Each qualifying automation is one alert row. |
| Sentiment key | mc_alert_automation_broken |
| Roles | owner, marketing, engineering |
Calculation
Calculated automatically from your Mailchimp data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A homeware brand on Shopify running Mailchimp Standard with three revenue-bearing automations. Snapshot taken Tuesday 09 Jun 26, 14:00.| Automation | Type | Status (Mailchimp UI) | Last send | Hours silent | Alert? |
|---|---|---|---|---|---|
| Abandoned Cart Recovery | Customer Journey | sending | 06 Jun 26, 11:20 | 74.7 | Yes |
| Welcome Series | Customer Journey | sending | 09 Jun 26, 13:05 | 0.9 | No |
| Post-Purchase Cross-Sell | Classic Automation | sending | 09 Jun 26, 08:40 | 5.3 | No |
-
Abandoned Cart Recovery has been dark for nearly three days while showing a healthy
sendingstatus. This is the exact silent-failure pattern the card exists to catch. Nothing in the Mailchimp dashboard flags it, the journey looks live, but no cart-recovery emails have gone out since 06 Jun. - The likely cause is a broken trigger or feed. Abandoned-cart journeys depend on a cart event arriving from the connected store. The first thing to check is whether the Shopify connection re-authorised cleanly, the cart-abandoned event is the most common one to silently stop when a store token expires. The second check is the journey’s first step: a UI version migration sometimes leaves the trigger disconnected.
-
The revenue at stake is concentrated. Abandoned-cart recovery is typically one of the top two highest-ROI automations in any account. Three days dark on a brand doing meaningful cart volume is a material, fully recoverable revenue loss. Cross-reference
abandoned-cart-recovery-value, it will have dropped toward zero over the same window. - The other two automations are healthy. Welcome Series sent within the last hour and Post-Purchase within the last six hours, both well inside normal cadence for their volumes. They correctly do not trip the alert.
- Open the named automation in Mailchimp. Confirm the status really is
sendingand look for a paused or draft step inside the journey. - Check the trigger. For store-driven journeys (abandoned cart, post-purchase, browse abandonment), verify the store connection is authorised and the relevant event is still flowing. For date or signup triggers, verify the trigger step is connected.
- Send a test through the journey. A template-render error surfaces immediately in a test send, a broken merge tag, a missing product block, or a dynamic-content rule that resolves to nothing.
- Check the serving audience or segment. If the segment condition now matches zero members, the journey has nobody to send to. This happens after a segment definition edit.
- Republish and confirm recovery. After the fix, watch for the last-send timestamp to advance on the next sync; the alert clears automatically once sends resume.
| Time horizon | Action |
|---|---|
| First 15 minutes | Open the named automation, confirm it is genuinely dark, and identify whether the failure is trigger-side or render-side. |
| First hour | Apply the fix (re-auth store, reconnect trigger step, correct the template) and send a test send to confirm render succeeds. |
| First 4 hours | Republish, confirm sends resume, and estimate the recoverable revenue lost during the dark window from the paired revenue card. |
| First day | Add a recurring monthly check of all revenue-bearing journeys; silent automation failures cluster around Mailchimp UI version migrations. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
automation-status | The full status view of every automation. This alert is the urgent subset; the status card is the standing inventory. |
automation-series-completion-rate | Completion rate degrades when a mid-journey step breaks. A dark automation here often shows up there as a completion cliff. |
abandoned-cart-recovery-value | The revenue card for the single most common automation to silently fail. Pair to size the loss when an abandoned-cart journey goes dark. |
welcome-automation-status | Welcome journeys are the second-most-common silent failure. Status check for the first-impression flow. |
top-automations-by-revenue | Tells you which dark automation costs the most. Triage by revenue, not by alphabetical order. |
automations | The automation inventory list. Use to confirm an automation still exists and has not been archived. |
customer-journeys | Customer Journey specific view; most modern automations are Journeys and break differently from Classic Automations. |
deliverability-drop | If an automation is sending but emails are not arriving, the failure is deliverability not trigger. Different root cause, different fix. |
Reconciling against Mailchimp
Where to look in Mailchimp’s own dashboard:- Mailchimp → Automations → Customer Journeys for the journey list and per-journey status. Open each revenue-bearing journey and check the status badge and the activity feed.
- Mailchimp → Automations → Classic Automations for older multi-step automations that predate Customer Journeys.
- Mailchimp → Reports → Automations for per-automation send counts; a flat or zero send count over recent days confirms the dark state this card detects.
sending status badge looks identical whether the journey sent 10,000 emails yesterday or zero. Reconciliation is therefore confirming the dark state, not disputing a number:
| Reason | Direction | What to do |
|---|---|---|
Status badge looks healthy. Mailchimp shows sending even when no sends are occurring. | Mailchimp looks fine, Vortex IQ flags it | This is expected. Trust the send-count, not the status badge. Open Reports → Automations to confirm zero recent sends. |
| Legitimately low-volume journey. A journey serving a tiny segment may genuinely send rarely. | Vortex IQ may flag a low-traffic journey | Confirm whether the journey should be firing. If the audience is small by design, the 24-hour window may need context; if it serves a large audience, the dark state is real. |
| Refresh lag. The alert evaluates on each sync cycle; a journey that resumed sending minutes ago may still appear flagged until the next sync. | Vortex IQ clears slowly after a fix | Wait for the next sync, then confirm the last-send timestamp has advanced and the alert has cleared. Check last_synced_at. |
| Time-zone of last-send timestamp. The 24-hour threshold is computed in UTC. | Edge cases near the boundary | Convert the Mailchimp last-send time to UTC before comparing against the threshold. |
sending badge reflects configuration state, not actual send activity. The card detects the gap between “configured to send” and “actually sending”. Point them at Reports → Automations to see the zero recent send count, then walk the trigger or template check.
Known limitations / merchant FAQs
The card flagged my automation but it is sending fine now. False alarm? Probably not, more likely the failure was real and self-resolved (a transient store-feed hiccup, an expired token that re-authorised), or you fixed it before reading the alert. The alert fires on the dark-state condition at evaluation time and clears once sends resume. A brief flag that clears on its own is worth a glance at the journey’s recent history to confirm there was no extended gap. Why 24 hours and not sooner? Twenty-four hours is wide enough to avoid false alarms from genuinely low-cadence journeys (a re-engagement series that sends one email a week, a birthday automation) while still catching a high-revenue journey before a second day of lost sends accumulates. For abandoned-cart recovery on a high-volume store, a shorter threshold would be useful; that finer-grained monitoring lives in the per-automation revenue trend rather than this binary alert. Does a paused automation trigger this? No. A paused or draft automation has a status other thansending, so it does not meet the alert condition. This card targets the specific trap of an automation that is configured to send but is not sending. A deliberately paused journey is a different (intentional) state.
One of my journeys serves a seasonal audience and is dark on purpose. Can I exclude it?
The alert is read-only and surfaces the condition; it does not auto-suppress journeys. For a journey that is intentionally dormant out of season, the practical approach is to set its status to paused rather than leaving it sending, which both reflects reality and removes it from this alert. A genuinely paused journey is the correct state for “off for now”.
Can Vortex IQ restart the automation for me?
No. Vortex IQ is read-only by design. It detects the dark state, names the affected automation, and points at the likely cause; the republish happens in Mailchimp by the merchant’s team. The Vortex Mind Customer Recovery Opportunity report can raise a merchant-side Action describing the fix, but the configuration change stays with the merchant.
The automation is sending but the emails are not arriving. Is that this card?
No, that is a deliverability problem, not a trigger problem. If the last-send timestamp is advancing (sends are leaving Mailchimp) but recipients are not receiving them, check deliverability-drop and sender-reputation-risk instead. This card only knows whether sends are leaving, not whether they land.