Most problems come down to a handful of causes. They’re ordered here by how often merchants hit them, and every one has a fix.
“I connected everything but nothing syncs”
Almost always one of two things, and both have a quick check.
1. Cron isn’t running. Sync happens through a background queue, so without cron nothing is sent and no error appears on screen. In the admin, open the Queue Monitor tab (Marketing → Intuit Mailchimp → Dashboard): if Pending keeps rising and never clears, cron is the culprit. Ask your host to confirm Magento’s cron is scheduled; once it runs, the Cron Monitor tab shows every job green.
2. Your database is below the minimum. The extension needs MySQL 8.0+ or MariaDB 10.6+ for background sync. If cron is running and Pending still won’t clear, check your database version and upgrade if it’s below the minimum.
Install or upgrade fails (setup:upgrade or di:compile errors)
Installing with Composer enforces the requirements for you (Magento 2.4.6+, PHP 8.1 to 8.4, MySQL 8.0+ or MariaDB 10.6+), so a clean refusal means the environment needs to meet that floor. If you install from a zip instead, install the bundled PulseCore package into app/code first, or di:compile stops on a class-not-found error. setup:upgrade adds columns to a few core tables, so large stores should run it inside a maintenance window. If a compile fails after an update, move to the latest patch release and re-run setup:upgrade, di:compile and cache:flush. Installation has the full walkthrough.
What the status labels mean
Every order, customer and product shows a status:
| Status | Meaning | Do you need to act? |
|---|---|---|
| Synced | Sent to Mailchimp | No |
| Up to date | Nothing changed, so it was skipped | No |
| Pending | Waiting for the next cron run | Just make sure cron runs |
| Error | A recent send failed; may self-heal | Check back in a few minutes |
| Action needed | Failed for good after retries | Fix the data, then Retry it in the Entity Queue |
| Not supported | A custom-type product is missing its SKU or name; nothing was sent | Add the SKU or name, then resync (below) |
| Not in Mailchimp | Never sent; out of sync scope | Only if you expected it (below) |
Why “Not in Mailchimp”? It’s not an error: the record was out of sync scope. Its store view isn’t connected, it’s older than your sync window, or it’s a historical order outside your confirmed-revenue selection. By default, confirmed revenue means processing, complete and closed: that selection decides which historical orders are imported and which orders count toward revenue and lifetime value. New orders sync as they happen and stay updated through every status change.
“Invalid email” errors, but I can’t find that customer
A guest checkout has no customer account, so the email lives on the order, not in the Customers grid. Look in Sales → Orders.
Mailchimp rejects addresses that look fake or malformed. Real guest emails sync fine; only invalid ones are excluded, on purpose. To fix one, open the order, correct the billing email, and save (it re-queues on its own). On test stores, sample data often carries placeholder emails Mailchimp will reject; that’s expected, not a fault.
Connection issues
- A banner says “Mailchimp is disconnected”: the fix travels with the message. The banner carries its own Reconnect to Mailchimp button, and one click restores the link. If you ever need the deeper route, open the Mailchimp accounts page (the overflow ⋯ menu on the ops tab strip), choose Reconnect there, then confirm your store view still points at the right audience.
- The header says “Not Connected” after adding an account: adding an account and connecting a store view are two separate steps. Switch the scope to a store view, then choose Connect store.
- “Connect store” shows no stores: either no account is connected yet, or every Mailchimp store is already linked to another store view. Add an account, or create a new store in Mailchimp.
- The login popup won’t finish: allow popups for your admin domain, and make sure your server can reach Mailchimp over HTTPS.
“It says my API key is invalid, but the key is brand new”
First check the format: a Mailchimp key ends with its data-center suffix (for example -us21), so generate a fresh key and paste it whole. If the key is definitely valid, the log under var/log records every validation call with the key masked: a line with HTTP 401 means Mailchimp rejected the key itself, while a transport error with no status means your server could not reach Mailchimp, so ask your host to allow outbound HTTPS to <dc>.api.mailchimp.com. A key that goes bad later shows on the Mailchimp accounts page: the account’s health indicator changes within the hour, and Update key fixes it right there, with no store disconnect. Connect your Mailchimp account covers each step.
Tags not appearing on contacts
Category tags apply to every order that syncs from the moment you enable them, and a re-sync tags your order history too: tags are never duplicated, so re-syncing is always safe. They go to shoppers with a customer account; guest purchases enrich the purchase data fields instead. Tags, data fields & segmentation covers how each tag is built.
Purchase fields blank on older contacts
The purchase data fields are created automatically on a contact’s first sync. If they show blank on contacts that were already in your audience, Rebuild merge fields (or a re-sync) fills them in. Tags, data fields & segmentation explains what each field tracks.
“Mailchimp’s campaign revenue doesn’t match my store”
A sudden drop to $0 across all campaigns means orders stopped reaching Mailchimp: check the Queue Monitor and the Cron Monitor first. Which orders count is a setting: Order Statuses to Sync (Configuration → Ecommerce Sync) decides what counts toward revenue, and cancellations are pushed with zeroed totals, so they never inflate it. Credit going to the wrong campaign is designed out: the extension never assigns a campaign to an order; attribution is Mailchimp’s own click tracking. When the numbers still disagree, each surface measures a different slice, and Why your numbers differ from Mailchimp has the full breakdown.
Products look wrong in Mailchimp: missing images, odd prices, stale details
Fix the catalog data first: a product with no image in the Base role syncs without an image, and price comes from the store view scope you edit. Then push it again: Push Now on the product’s Mailchimp tab re-queues it at real-time priority, and the Push to Mailchimp mass action or bin/magento mailchimp:resync always send, even when nothing changed in Magento. The Entity Queue row’s detail shows the exact payload that went out, so check it soon after pushing. Prices sync as the catalog final price with no tax added, and Mailchimp shows one live selling price per product, which is expected. Adobe Commerce gift cards carry a representative price (the smallest configured amount, or the open-amount minimum), and a zero-priced custom-type product falls back to 0.00. Order totals and line prices always come from the amounts actually paid, so an open-amount gift card is reported at the exact amount the shopper chose. How syncing works explains what is sent and when.
Mapped data fields come through empty or stop updating
Custom mappings live in the Data fields grid (Configuration → Contact Sync) and are edited at store view scope, because each store view maps to its own audience. Create the merge field in Mailchimp first: the dropdown lists only tags that exist in that audience, so a typo can never be saved. Saving a real change re-queues every affected contact, and Rebuild merge fields forces the same refresh, which also fills fields that show blank on contacts pre-dating the mapping. If a field quietly stops updating, the usual cause is that its tag was deleted in Mailchimp: re-create it there or clear the row. Tags, data fields & segmentation covers every field.
Guests not appearing after abandoning carts
Mailchimp needs an email address to send a reminder, and the extension captures one the moment a guest types it anywhere: at checkout, in a newsletter box, or arriving from a campaign link. If guest carts aren’t showing up, confirm the store view is connected; a guest who never shared an email anywhere can’t be reminded, and every other cart flows on its own. Recover abandoned carts shows the whole journey.
“My abandoned cart automation never sends an email”
Recovery emails are sent by your Mailchimp automation, not by the extension, so start on the Abandoned Carts panel of the Dashboard: if carts are being counted but nothing sends, follow the panel’s Set up automation link to finish the automation in Mailchimp. If Total Carts stays at 0, open the Cron Monitor (carts ride the Boost lane) and the Queue Monitor, and confirm that store view is connected. A completed order removes its cart from Mailchimp right away, so shoppers never get a reminder for something they already bought, and recovery links for registered customers land on the login page by design. Recover abandoned carts walks through the whole journey.
The Pixel switch won’t turn on
The switch flips only after Mailchimp confirms the activation, so when it stays off, the extension’s own popup tells you why and names the store view involved. The common case is two store views sharing one web address: each Pixel lives on its own domain, so one of the views carries it. Behavioral events keep flowing server side for every store view regardless, so segments and Customer Journeys keep working. The Mailchimp Pixel & behavioral events has the details.
The Pixel is active but nothing fires on the storefront
Open the storefront with your browser’s dev tools and the page tells you which of three known behaviors you are seeing. If your cookie-consent banner has not been accepted yet, the Pixel is held back on purpose: accept it and the script injects within about a second. If the console shows a Content-Security-Policy violation naming chimpstatic.com or mcjs.prd.a.intuit.com, the block comes from a CSP set outside Magento: add both hosts to script-src and connect-src there. If it is an inline-script hash mismatch on checkout, update the extension: each release ships the current approved hash. Server-side events keep flowing regardless, on the Events Tracking tab. The Mailchimp Pixel & behavioral events explains both halves.
The subscribe checkbox isn’t showing
Three quick checks: flush the Magento cache; see whether the Pixel is active on that store view (the checkout checkbox steps aside on purpose, so the confirmation page carries no overlapping prompts); and confirm Sync Newsletter Subscribers is on in the Contact Sync settings, which is what makes the opt-in surfaces available. Grow your audience covers both checkboxes.
Unsubscribes made in Mailchimp aren’t reaching Magento
Webhooks register themselves during Go Live, so start at the audit surface: open Webhooks from the ops menu, click Check Webhooks and pick the store view. A healthy store shows “Webhooks are active”; if it offers Register instead, click it (or Re-register if your store URL changed). When registration fails, the window explains why, and the common case is Mailchimp being unable to reach your store URL (firewall, maintenance mode, or a password-protected staging site): make it publicly reachable and register again. Unsubscribes apply the moment they arrive; profile changes also need Sync Newsletter Subscribers on. Unsubscribes & consent covers the two-way flow.
Confirmation emails arrive twice, or subscribers sit at “pending”
Treat the extension’s Double Opt-In toggle (Configuration → Contact Sync) as the single confirmation knob: with it on, Mailchimp sends the one confirmation email and owns the confirm step. Leave Magento’s own Newsletter “Need to Confirm” setting off unless you deliberately want a second confirmation email: with both on, subscribers get two emails and stay pending until they click Mailchimp’s link. If a customer re-subscribes but never reappears, the API Log shows the compliance-locked entry: Mailchimp protects contacts who opted out through a campaign link, and they re-join through a Mailchimp-hosted signup form. Unsubscribes & consent explains consent in both directions.
We changed domains and sync paused
It paused on purpose: this is the protection that keeps a moved or cloned store from writing to the wrong place. When your store’s address changes, after a domain change, a server move or a copied environment, the extension pauses that store view and an admin banner explains what happened. Disconnect and reconnect the store view and sync resumes; Connect your Mailchimp account walks through the connection steps.
A banner says our linked Mailchimp store was deleted in Mailchimp
Nothing is lost: sync never writes against a missing store, and queued changes wait safely at Pending. Either restore the store on the Mailchimp side (an hourly health check clears the pause on its own), or switch Configuration to the affected store view, disconnect from the connection popup and reconnect through the Setup Wizard; data re-syncs automatically. If a Mailchimp store already exists on the same domain when you reconnect, the wizard offers to archive it and create a fresh one, with your audience untouched. Is it connected and syncing well? shows every connection signal in one place.
New activity syncs but history stalls (or the reverse)
Boost and Backfill each run in their own cron group, so a host that only runs Magento’s default group starts just half the engine. Ask your host to confirm Magento’s cron runs all groups; the Cron Monitor shows each group’s state, so you can see exactly which one is waiting. How the sync engine runs explains the two lanes.
“My audience is much bigger than my subscriber list” (contact count and billing)
Contact volume is bounded by design and previewed before anything syncs: the Setup Wizard shows an estimate for the history window you pick (3, 12, 24, 36 or 48 months, or everything), so a shorter window bounds the count. Sync Customers only ever syncs customers who have placed an order, never your whole customer database, and Default Subscription Status for Synced Customers decides whether they land as subscribed or non-subscribed. If the audience is already larger than you want, archive contacts in Mailchimp: archived contacts are not billed and return on their own if the shopper buys again. How syncing works explains exactly who syncs and when.
A promo rule is stuck on “Action needed”
First confirm Sync Promo Rules & Codes and Enable Ecommerce Sync are both Yes (Configuration → Ecommerce Sync). When Mailchimp turns a rule down (a zero discount, missing dates, a missing name), only that rule waits: open the Entity Queue tab, filter Status by “Action needed” and read the Status Message for the exact reason. Fix the Cart Price Rule in Magento, then click the row’s Retry link: re-saving the rule alone does not revive the row. Everything else keeps syncing while it waits. Keep an eye on your sync shows how to read the queue.
A product shows “Not supported” in the Entity Queue
This amber status appears only for a custom-type product (an Adobe Commerce gift card or a type from a third-party extension) that is missing its SKU or its name: nothing was sent, and the Status Message names the product type. Custom-type products with a SKU and a name sync automatically with a best-effort payload, recorded in the API Log as generic_type_fallback. Add the missing SKU or name, then use the row’s Retry on the Entity Queue (or run Resync All Data from Manage Connection, on the Manage tab); re-saving alone does not clear the row. An order holding the product parks at “Action needed” naming its SKUs; once the repaired product has synced, use Retry on the order’s row. Re-syncing and command-line tools has the details.
Still stuck?
Open the Queue Monitor, find the record that won’t sync, and read the full Mailchimp error; it usually names the fix. If you’re still blocked, ebizmarts support is one email away: include your Magento version, database version, extension version, and a screenshot of the error.