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 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, and here’s how we work through them.

The quick triage path

If the automation stopped firing, work 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, and the rest of this post walks each one in detail.

Start with the trigger and prove it’s catching events

Open the journey 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 fires on “tag added” while the CRM writes to a merge field, the trigger is “Order completed” while the store posts “Paid,” the trigger watches the Newsletter audience while the form submits 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, and new journeys default to only new qualifying events after publication unless you explicitly toggle existing contacts in, meaning anyone who matched yesterday won’t enter today. Then open the Activity view and read the actual counts, entered, queued, skipped, errors. If entered is zero and the trigger is configured correctly, the problem is upstream in the data, integration, or audience setup, not in the journey logic.

Confirm contacts are actually eligible to enter

For marketing automations, Mailchimp only sends to subscribed, deliverable contacts, so the first check on a stuck journey is the status of the test contacts who should be entering. Unsubscribed and Cleaned don’t receive marketing email, Non-subscribed (transactional only) don’t, and Pending contacts waiting on double opt-in confirmation don’t. If your test contact is in any of those states, the journey is doing the right thing by not sending.

Audience and field mapping is the next layer: the journey is tied to one specific audience, and data flowing into a different one is invisible to it. Merge field filters stall in a subtler way, a condition like “Status equals true” won’t match contacts whose field reads “Yes” or “1” or “TRUE” in caps, and the fix is standardizing values at the source rather than patching in the segment, or the inconsistency keeps biting. Tag-based entry is where casing and spacing matter most: a condition on “Tag is VIP-Customer” won’t match an integration writing “vip-customer” or “VIP Customer” with a space, so pick one canonical version and enforce it everywhere that writes tags.

Last on eligibility: re-entry rules. By default a contact enters a journey once, which breaks reorder reminders, renewal cycles, and anniversary flows unless re-entry is explicitly enabled with a reset condition or rolling date logic so the same contact can qualify again. Exclusion segments and frequency caps can also block sends silently without surfacing as errors, so check both when 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. Every email step has a send window and an account-level time zone, and if the window is Monday through Friday, 9 to 5, someone who qualifies Friday at 5:01 waits until Monday at 9. That’s not a bug, that’s the rule you set. Wait steps compound it: “wait 3 days, then send at 8 AM” slips to Monday when day three lands on a Saturday your window excludes, and a few stacked conditions like that turn a two-day follow-up into a week-long gap that looks like a freeze. Simplify wait logic to plain hours when precision isn’t critical, and audit the windows to make sure they’re not narrower than the journey needs.

Send Time Optimization is the other invisible deferral. Enabled on a journey email, it holds the send until Mailchimp predicts the best moment per contact, which can mean hours or days of delay, useful in one-off campaigns and frustrating inside time-sensitive automations. We usually turn it off inside journeys and let the explicit schedule do the work, the same STO-belongs-in-campaigns position we took in our send time optimization breakdown.

Verify the integrations that feed the trigger

If the trigger depends on data from outside Mailchimp, the integration is the most fragile part of the system. Ecommerce triggers depend on the store connection syncing orders in real time with statuses mapped to the exact event the journey listens for, and we’ve seen Shopify connections that show as connected while having synced nothing for weeks over a permissions issue nobody noticed. The test is a real order watched in the Activity view: entry within a few minutes means healthy, nothing means the sync is the problem, not the journey.

Site tracking triggers, page visits, abandoned cart, depend on the tracking script installed on every relevant page, the domain verified, and cookies surviving your consent banner, and aggressive consent setups can suppress the script for a meaningful share of visitors, making site-based triggers look unreliable when they’re actually being blocked before they can fire. Third-party forms and middleware are the other usual suspects: Typeform, Webflow, Facebook Lead Ads, and Zapier all need to post into the exact audience the journey watches with the right mappings and tags, and Zapier tasks fail silently more often than people realize, so check the task history when a journey goes quiet, since a failed run with no notification can be the entire problem. API keys and credentials expire, rotate, and lose scopes during platform updates too, and a key that broke last month means a journey that’s received nothing since. 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 the four checkpoints are worked, provoke a controlled event and watch 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 entry within the expected window. If it enters, the journey is healthy and the original problem was upstream. If it doesn’t, you’ve narrowed the failure to a specific stage and know exactly where to look next.

Mailchimp automations don’t fail at random, they fail at specific, traceable points in the chain, and when you verify the trigger, prove eligibility, audit the schedule, and harden the integrations, the journey fires 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 ever reach the “why isn’t this working” stage.