If you’re a growth or ops manager on a Shopify Plus or WooCommerce store asking why is my triggered campaign not sending, the honest answer is that you probably won’t find out from the dashboard itself — you’ll find out because a metric drifted. Cart-recovery revenue looks soft for the third week running. A subscriber messages support asking why they haven’t gotten a restock alert in a month. Someone finally opens the automations tab they haven’t touched since March and notices the back-in-stock trigger has said “Paused” the whole time.
That’s the actual failure mode for triggered campaigns and RSS auto push notifications: not a crash, not an error banner, just quiet. A cart abandonment campaign paused mid-sale and never resumed doesn’t announce itself. Neither does an RSS feed that broke when the site moved to a new CMS. Both keep showing up in the campaign list looking exactly like they always have, right up until someone asks the right question — and by the time someone does, the answer is usually measured in weeks, not minutes.
This post is that question, asked in plain language instead of a dashboard crawl: using two read-only tools built into the PushEngage MCP server, pushengage_list_triggered_campaigns and pushengage_list_rss_campaigns, to pull triggered campaign analytics and RSS-feed health in one pass and catch a paused or broken automation before it costs another week of revenue.
The three-week gap nobody notices
Triggered campaigns and RSS auto-push share one property that makes them uniquely easy to lose track of: once they’re built, they run without anyone touching them again. That’s the whole point — a cart-abandonment trigger, a price-drop alert, a back-in-stock notification, an RSS feed that auto-pushes every new post. Set it up once, and it fires forever on its own schedule.
Except “forever” assumes nothing ever changes underneath it. A trigger gets paused during a sale to avoid overlapping with a promotional blast, and nobody remembers to turn it back on. An RSS feed URL shifts during a site migration, and the campaign that was pointed at it keeps saying “Active” while quietly firing on nothing. A back-in-stock trigger’s inventory feed stops syncing, and the trigger has nothing left to fire on. In every case, the campaign looks fine in the list view. It just isn’t doing anything.
Put a number on it, illustratively: a mid-market cart-abandonment trigger recovering something like $1,800 a week in cart value isn’t an unusual figure for a Shopify Plus account with steady traffic. Three silent weeks — the length of time it typically takes for someone to notice on their own — is $5,400 of recovered revenue that never got recovered, and nobody knew to go looking until the top-line number forced the question.
Why triggered campaigns and RSS feeds break quietly
Both automation types fail through a small, boring set of causes, and none of them trip an error state a marketer would ever see.
- A pause outlives its reason. A cart abandonment campaign paused mid-sale, to keep it from competing with a blast campaign for “just this week,” rarely gets un-paused on schedule — the person who flipped the switch moves to a different project, and six months later it’s still sitting there, still marked paused, with nobody sure why.
- An upstream integration goes quiet. A price-drop or back-in-stock trigger depends on an inventory or pricing feed from the store platform. If that feed stops syncing — a plugin update, an app disconnect, an API key that expired — the trigger has nothing left to check against and simply never fires again.
- The feed URL moves. A CMS migration, a blog re-platform, or a domain change can quietly break the RSS feed an auto-push campaign points at, without touching the campaign’s own settings at all. The campaign still says active because, as far as PushEngage’s own settings are concerned, nothing changed.
- A browse-abandonment rule stops matching. If a site redesign changes URL structure or removes the page a browse-abandonment trigger watches, the trigger keeps running but has nothing left to catch.
- A one-off exception becomes permanent. A trigger gets disabled for a single product line during a recall or a supplier issue, and the re-enable step falls off everyone’s list once the original problem is resolved.
None of these produce a support ticket to the marketing team. They produce a support ticket to customer service, three weeks later, from a subscriber wondering where their restock alert went — which is the slowest, most expensive way to find out, and the one every audit in this post is built to skip.
Why your triggered campaign isn’t sending (and how to check in five seconds)
The fastest way to answer “why is my triggered campaign not sending” is to stop guessing and ask for the list. pushengage_list_triggered_campaigns returns every triggered campaign on your site filtered by status — active, paused, or draft — and with include_analytics set, each one comes back with sent, seen, and clicked counts for the period.
That single call does the first fifteen seconds of triage for you, sorting every result into one of three states:
- Fully dark — status is active, but sent count is zero (or near-zero) for the period. Something upstream broke.
- Correctly quiet — status is active, sent count is low, but that matches the trigger’s real volume (a back-in-stock alert only fires when something actually restocks; a quiet week isn’t a bug).
- Actually paused — status says paused, plain and simple, and someone needs to decide whether that was deliberate.
Laid out for an illustrative mid-market eCommerce account running four triggered campaigns:
| Triggered campaign | Status | Sent | Seen | Clicked |
|---|---|---|---|---|
| Cart abandonment | Active | 3,940 | 2,610 | 210 |
| Browse abandonment | Active | 0 | 0 | 0 |
| Price drop alert | Active | 812 | 590 | 61 |
| Back-in-stock alert | Paused | 0 | 0 | 0 |
Two findings jump out immediately. The back-in-stock trigger is paused — worth confirming whether that was intentional, since every subscriber waiting on a restock alert is getting nothing while it sits that way. The bigger problem is the browse-abandonment trigger: it’s marked active, but zero sends means it’s fully dark, not correctly quiet — a site change most likely broke the page rule it watches, and every browse-abandoning visitor since then has gotten no follow-up at all.
Notice what the price-drop alert is doing here: 812 sends is a smaller number than the cart-abandonment trigger’s 3,940, and that’s fine — a price-drop alert only fires when a price actually drops, so a lower volume is correctly quiet, not a red flag. The skill this section is really teaching is telling those two apart without guessing: a trigger with sends near its own historical baseline is healthy at any volume; a trigger that used to send regularly and has dropped to zero is broken regardless of how small it was to begin with.
Worth stating plainly: pushengage_list_triggered_campaigns lists and reads. It doesn’t re-enable a paused campaign, fix a broken page rule, or edit a trigger’s conditions — the fix still happens in the PushEngage dashboard. What this tool does is tell you, in one call, exactly which of your triggered campaigns need that fix and why, instead of clicking through each one to find out. That’s the whole value of pulling triggered campaign analytics through chat instead of a dashboard tab: the finding takes five seconds, and the fifteen minutes you’d otherwise spend scrolling gets spent on the one campaign that actually needs it.
For the underlying question of which events are actually worth building a trigger for in the first place — which events deserve trigger campaigns covers the three trigger-worthiness tests PushEngage uses across cart abandonment, browse abandonment, price drop, and back-in-stock.
Catching an RSS feed that quietly stopped pushing
RSS auto push notifications fail on the same “looks fine, isn’t” pattern as triggered campaigns, just with a different cause: instead of a paused status or a broken page rule, the failure usually sits in the feed itself.
Ask your assistant to list your RSS campaigns with status and analytics, and pushengage_list_rss_campaigns returns each campaign filtered by status, with the same sent/seen/clicked breakdown when analytics are included. The tell here is nearly identical to the triggered-campaign case: a campaign marked active with a sent count that’s dropped to zero, or dropped sharply from its normal baseline, almost always means the feed it’s watching stopped publishing correctly.
The usual culprit is small and easy to miss: a content team switched CMS platforms, changed the feed’s URL path, or a plugin update altered how the feed formats its items, and nobody told whoever owns push notifications. For a site running a decent publishing cadence, RSS auto-push is usually the highest-volume automation on the account precisely because it fires on every new post — which also means a broken feed goes from “quiet” to “a real gap in returning traffic” faster than almost anything else on this list.
A quick before/after comparison makes the break obvious, illustratively:
- Normal week: RSS campaign fires 6–9 times as new posts publish, matching the site’s normal content cadence.
- Broken week: RSS campaign shows active, zero sends, and the site has published four new posts in the same window — a clear signal the feed connection, not the content calendar, is the problem.
Same accuracy note as above, restated because it matters just as much here: pushengage_list_rss_campaigns lists and reads status and performance. It can’t re-point a broken feed URL or restart the campaign itself — that correction happens in the dashboard once you know which feed to look at, usually by re-validating the feed URL in the RSS campaign’s settings and confirming it still resolves to the right domain. If you haven’t set an RSS auto-push campaign up yet, setting up an RSS auto-push campaign walks through the configuration; this post assumes one is already running and just needs a health check.
Adjacent automation types worth glancing at in the same pass — creating a price drop notification campaign and setting up back-in-stock push notifications — cover the setup side of two of the triggered-campaign types this audit checks. And if drip campaigns or Workflows are also part of your automation stack, auditing drip campaigns and workflows covers that adjacent pair the same way this post covers triggered campaigns and RSS.
Getting started: connecting the PushEngage MCP server
Running this check from a chat window starts with adding the PushEngage MCP server to your assistant’s config. For Claude Desktop or Cursor, that’s one entry in the client’s MCP config pointing at npx -y @pushengage/mcp — no separate install needed, since npx fetches the server on demand. Claude Code works the same way.
Restart the client, ask it to log you into PushEngage (a browser tab opens to authorize the connection, so your credentials never pass through the assistant), then ask to see your sites and select the one you want to work with. Every site-scoped tool, including both tools in this post, defaults to that site afterward. For the full walkthrough — config file paths, first-run login, and what to do if the connection won’t start — see the full PushEngage MCP setup guide.
Building this into a weekly habit, not a one-time check
The point of this audit isn’t to find the one broken campaign today. It’s to make checking for one a five-second question instead of a project nobody schedules. PushEngage moves at real volume — 25,000+ business owners across 150+ countries send more than 15.2 billion notifications a month through the platform — and at that scale, a paused trigger or a broken feed doesn’t cost a click or two. It costs the recovered cart value or the returning-visitor traffic that automation was built to capture, for exactly as long as it stays silent.
That’s the case for asking, out loud, “why is my triggered campaign not sending” on a Monday instead of finding out from a soft revenue number in a monthly review. Ask your assistant to list your triggered campaigns and RSS campaigns with analytics, glance at the PushEngage plans if a trigger you’re missing turns out to be worth building, and spend the fifteen minutes you save in the dashboard fixing the one thing that’s actually broken.
