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. The extension does warn you: the Mailchimp card on the admin Dashboard flips to Background sync paused, and the System status tile on the Cron Monitor names the stuck schedule. To confirm, 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. A zip install of the extension alone compiles and runs; PulseCore is optional, not bundled. Add the PulseCore and Pulse bridge packages only if you want Pulse journeys, each unpacked under app/code, then re-run the same setup sequence. 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
Orders and customers show the full status set on their grids; the Products grid shows only Synced or Not in Mailchimp, with a product’s full state in the Entity Queue and on the product’s own Mailchimp tab:
| 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 (the Orders and Customers grids call it Needs Action) | 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 and correct the billing email, then open the Entity Queue and click Retry on the order’s row: a row still at Error keeps retrying on its own and picks up the fix, while a row at Action needed waits for your Retry. 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, switch Configuration to the store view and open Manage Connection: disconnect on the Manage tab, reconnect through the wizard, then confirm the store view still points at the right audience.
- The header still says “Let’s connect” after adding an account: the configuration header keeps showing its Log in to Mailchimp button because 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. Guest checkouts are tagged too when Update Audience Members from Guest Orders is on. 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. To read the attribution your store recorded, campaign by campaign, and to prove it against the Dashboard, open The Campaign Performance report. 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 always sends, even when nothing changed in Magento. On the command line, bin/magento mailchimp:resync --force does the same; without --force the command only previews what would be re-sent. 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.
Prices changed in Magento but Mailchimp still shows the old ones
When the storefront charges the new price and Mailchimp keeps the old one, the usual cause is how the price was written. The extension notices a product has changed by watching its last-updated date, and not every way of setting a price moves that date. Magento’s product import, the standard product-save API and the admin’s Update attributes mass action all move it, so prices written those ways reach Mailchimp within about a minute. Magento’s dedicated bulk special-price endpoint does not move it, and neither does anything writing to the database directly, so those changes are invisible to the extension, with no error and no warning. To check, open the product and compare its Last Updated date against the Last Sync shown on its Mailchimp tab and against when the price actually changed: a new price beside an old Last Updated confirms it. Point your ERP, PIM or repricer at a route that updates the date, then use Push Now on the product’s Mailchimp tab, or the Push to Mailchimp mass action, to correct what is already in Mailchimp. If you run integrations that write prices, this is worth confirming with whoever built them.
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 the panel’s Abandoned count 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”
Double Opt-In is set in Mailchimp: the Double Opt-In row in Configuration → Contact Sync is read-only and mirrors your audience’s setting, which lives in Mailchimp under Audience → Settings → Audience name and defaults. 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. Before you do, what happens if you disconnect or uninstall covers what this removes and what comes back.
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. Before you do, what happens if you disconnect or uninstall covers what this removes and what comes back.
New activity syncs but history stalls (or the reverse)
Boost runs in its own cron group (ebizmarts_mailchimp_boost) and Backfill in the extension’s main group (ebizmarts_mailchimp), and neither is Magento’s default group. A host that pins cron to specific groups can start one lane and not the other, so 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 previewed before anything syncs: the Setup Wizard shows an estimate for the choices you make, and that estimate is the number to trust, because it counts every contact that will be created, subscribers included. The history window you pick (3, 12, 24, 36 or 48 months, or everything) bounds order and cart history and the customers imported with it; it does not bound newsletter subscribers, who sync in full whichever window you choose. 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.