Est. reading time: 7 minutes
When a Mailchimp automation isn’t firing, the problem is almost never mysterious. It’s a specific checkpoint in the journey where the configuration, the data, or the integration doesn’t match what the trigger is actually listening for. The journey isn’t broken. It’s waiting for a condition that’s never going to be met, because something upstream is sending the wrong signal.
Most stalled automations we audit in client accounts fall into one of four buckets: the trigger isn’t catching the event, eligible contacts aren’t actually eligible, the schedule is silently deferring sends, or an integration broke and nobody noticed. Each has a specific diagnostic path. Here’s how we work through them.
The quick triage path
If the automation stopped firing, work through the failure points in this order:
- Trigger: Is Mailchimp receiving the exact event the journey is listening for?
- Eligibility: Is the contact subscribed, deliverable, in the right audience, and allowed to enter?
- Schedule: Is the journey waiting on a send window, time zone rule, wait step, or Send Time Optimization?
- Integration: Is the outside system still syncing the right data into Mailchimp?
Most failures get caught at one of those four checkpoints. The rest of this post walks through each one in detail.
Start with the trigger and prove it’s catching events
Open the Customer Journey or Classic Automation and read the starting point literally. What exact event is it listening for? Tag added, audience signup, merge field change, ecommerce purchase, page visit, API event. Then go to the system that’s supposed to send that event and confirm it’s sending the same thing.
This is where most “trigger isn’t working” problems actually live. The journey is set to fire on “tag added,” but the CRM is writing to a merge field. The trigger is “Order completed,” but the store is posting status as “Paid.” The trigger is “Signup to Newsletter audience,” but the form is submitting to a different audience entirely. The journey is doing exactly what it was told. It’s just not being told what you think.
Once the event match is confirmed, check the journey’s state. Drafts and paused journeys don’t accept entrants. New journeys default to “only new qualifying events after publication” unless you toggle existing contacts in, which means anyone who matched the criteria yesterday won’t enter today. Then open the Activity view and look at the actual counts: contacts entered, queued, skipped, errors. If the entered count is zero and the trigger is configured correctly, the problem is usually upstream in your data, integration, or audience setup, not in the journey logic itself.
Confirm contacts are actually eligible to enter
For marketing automations, Mailchimp only sends to subscribed, deliverable contacts. The first thing to check on a stuck journey is the status of test contacts who should be entering. Subscribed contacts receive marketing email. Unsubscribed and Cleaned do not. Non-subscribed contacts (transactional only) do not. Pending contacts (waiting on double opt-in confirmation) do not. If your test contact is in any of those last four states, the journey is doing the right thing by not sending.
Audience and field mapping is the next layer. The journey is tied to a specific audience, and if your data is flowing into a different audience, the journey will never see it. Merge field filters are another common stall point: a condition like “Status equals true” won’t match contacts where the field reads “Yes” or “1” or “TRUE” in all caps. Standardize the values at the source, not in the segment, or the inconsistency will keep biting you.
Tag-based entry conditions are where casing and spacing matter most. If your condition is “Tag is VIP-Customer” and your integration is writing “vip-customer” or “VIP Customer” with a space, the journey won’t match. Pick one canonical version and enforce it everywhere that writes tags.
Last on eligibility: re-entry rules. By default, a contact can only enter a journey once. For reorder reminders, renewal cycles, or anniversary flows, that’s a problem. You need re-entry explicitly enabled, plus a reset condition or rolling date logic so the same contact can qualify again. Exclusion segments and frequency caps can also silently block sends without showing up as obvious errors, so check those if your eligible contacts aren’t progressing.
Check the schedule before assuming the journey is broken
Plenty of stalled journeys aren’t stalled. They’re waiting, exactly as configured, for a send window that hasn’t opened yet. Every email step has a send window (days of the week, hours of the day) and an account-level time zone. If your window is Monday through Friday, 9 AM to 5 PM, and someone qualifies Friday at 5:01 PM, they’re waiting until Monday at 9 AM. That’s not a bug. That’s the rule you set.
Wait steps compound this. “Wait 3 days, then send at 8 AM” sounds straightforward, but if day three lands on a Saturday and your window excludes weekends, the actual send slips to Monday. A few stacked conditions like this can turn a “two-day follow-up” into a week-long gap that looks like the journey froze. Simplify wait logic to “wait X hours” when precision isn’t critical, and audit your send windows to make sure they’re not narrower than the journey actually needs.
Send Time Optimization is another invisible deferral. If it’s enabled on a journey email, Mailchimp will hold the send until it predicts the best time for each contact, which can delay things by hours or days. It’s a useful feature for one-off campaigns and a frustrating one inside time-sensitive automations. We usually turn it off for journeys and let the explicit schedule do the work.
Verify the integrations that feed the trigger
If your trigger depends on data from outside Mailchimp, the integration is the most fragile part of the system. Ecommerce triggers depend on the store being connected, orders syncing in real time, and order statuses mapping to the exact event the journey is listening for. We’ve seen Shopify connections where the store technically shows as connected but hasn’t synced new orders in weeks because of a permissions issue nobody noticed. The fix is to test with a real order and watch the Activity view for an entry within a few minutes. If nothing shows up, the sync is the problem, not the journey.
Site tracking triggers (page visits, abandoned cart) depend on the Mailchimp tracking script being installed correctly on every relevant page, the domain being verified in Mailchimp, and cookies not being blocked by your consent banner. Aggressive cookie consent setups can prevent the tracking script from firing at all for a meaningful portion of visitors, which makes site-based triggers look unreliable when they’re actually being suppressed before they can fire.
Third-party forms and middleware are the other common failure point. Typeform, Gravity Forms, Webflow, Facebook Lead Ads, and Zapier all need to post into the exact audience the journey watches, with the right field mappings and the right tags. Zapier tasks fail silently more often than people realize. If you rely on a Zap to add tags or update fields, check its task history when a journey isn’t firing. A failed run with no notification can be the entire problem.
API keys and integration credentials expire, get rotated, or lose scopes during platform updates. If a key broke last month and nobody caught it, the journey hasn’t been receiving events since then. One canonical naming convention, enforced everywhere, prevents the schema drift that turns a working automation into a silent failure.
Test with real events and watch the activity feed
Once you’ve worked through the four checkpoints, the final step is provoking a controlled event and watching the journey respond in real time. Add the trigger tag to a test contact. Submit the form. Place a test order. Then open the Activity view and confirm the entry happens within the expected window. If it does, the journey is healthy and the original problem was upstream. If it doesn’t, you’ve narrowed the failure to a specific stage and you know where to look next.
Mailchimp automations don’t fail at random. They fail at specific, traceable points in the chain. When you verify the trigger, prove eligibility, audit the schedule, and harden the integrations, the journey starts firing reliably because nothing is left guessing. Most fixes are simple once the failure point is clear, which is why clean data, consistent naming, and real-event testing prevent most automation problems before they reach the “why isn’t this working” stage.







