What I Check When Shopify Flow Silently Stops Firing

Open your Shopify admin. Settings > Apps and sales channels > Shopify Flow. Pick a workflow you have been trusting for months to tag customers, alert Slack, or route an internal email. Click Run history and read the status column for the last week.

If every row says Completed, that is not the same as working. It is the first thing I try to explain to merchants who write in asking why an automation they set up ages ago quietly stopped doing its job.

Quick answer. Flow has no Failed run status. Every run ends as Completed, including runs where the intended action never fired, which is why shopify flow silent failures survive for weeks before anyone notices.

What the merchant handed me

A few weeks ago a client asked me why their Klaviyo "first purchase" segment had stopped growing. They sell a mid-priced skincare line, they push somewhere in the neighbourhood of eighty orders a day, and they had built a Flow about eighteen months ago that reads the customer's tags at Order paid time, checks for the absence of a returning_buyer tag, then applies both a first_purchase tag and a Klaviyo property in a single pass.

For most of those eighteen months, that Flow worked. Then, sometime around late April, the count of new first-purchase members flowing into their Klaviyo list collapsed. Not zero. Just roughly a tenth of what they had been seeing.

Their team's first move was to open Shopify Flow, look at the workflow, see the green Active pill in the top-right, and close the tab. Nothing had changed on their end. No app installs. No theme edit. The workflow diagram in the editor looked identical to how they had left it. So they assumed the fall-off was a marketing problem and asked me to look at their ads instead.

I opened the Flow admin.

What I checked first

Run history for the workflow, filtered to the last seven days. Somewhere around six hundred runs, which was roughly what I would expect from their order volume. Every single one showed Completed.

That was my first bad sign. When the merchant told me the outcome was wrong for maybe ninety percent of new buyers, "every row Completed" and "the workflow is working" are two different sentences. That mismatch is where most shopify flow silent failures start hiding.

I clicked into three or four of the Completed runs at random and read them end to end. Trigger fired. First condition step evaluated. Second condition step evaluated. Tag action recorded as executed. Klaviyo property update recorded as executed. Green checkmarks the whole way down. The customer record in question did not have the tag on it. When I refreshed the customer page in the admin, still nothing.

So the run history says the tag was applied. The customer object says it was not. Somewhere between those two truths is where I needed to look, and it was not going to be in the Flow dashboard, because the Flow dashboard was already telling me a story that did not match reality.

Completed does not mean succeeded

This is the part I did not fully understand until I went and read Shopify's own developer forum on it.

Flow's Run history has five statuses: In progress, Waiting, Rate limited, Cancelled, and Completed. There is no Failed. A Shopify staff member named paul_n confirmed in the developer forum, in early 2026, that "Completed" does not indicate success or failure. An action can raise an internal error, halt that branch of the run, and Flow will still record the run as Completed. Every row.

The consequence is that the built-in "Workflow error occurred" trigger, which most merchants (including me, at one point) install as their safety net, is fired against a status Flow does not actually maintain. The trigger has a documented 30-day deduplication window: it fires at most once per workflow version within that window. So the safety net catches, at best, one blip a month per workflow. And it only catches things that Flow's internal error model considers errors.

Connector failures where the action returned a soft error to Flow: not covered.

Runs where all steps show green but the downstream action did not actually execute: not covered.

Infrastructure-level outages where the trigger event never reached Flow at all, so there is no run history row to be flagged: obviously not covered.

If you are relying on that trigger and a green dashboard as your monitoring surface, you are not being monitored. You are being reassured. This is the mechanism behind most shopify flow silent failures I run into.

The dead ends I ran through first

I did not go straight to the right answer. I never do.

My first guess was the Slack connector, because that had bitten a different client of mine the year before, when their marketing lead swapped Slack workspaces and the Flow lost its OAuth without surfacing anything. This client did not use the Slack connector, so I ruled it out in about a minute. Fine.

My second guess was a compareDigest race. Two workflows both touching the same order at Order paid time, one of them losing the digest comparison and getting stuck on "Running" while the other completes. This is a documented pattern. I checked, and they only had one workflow on the Order paid trigger. Ruled out.

My third guess was the customerJourneySummary lag. There is a known two-to-three-minute delay between Order paid firing and the customer's attribution fields populating, so a workflow that reads first-visit source at trigger time evaluates against null. I looked at their workflow condition set. It did not touch customerJourneySummary. Ruled out.

My fourth guess was the Winter Update inventory race, where post-update the timing of inventory finalization relative to Flow evaluation stopped being deterministic. They were not reading inventory. Ruled out.

At that point I had a client whose Flow was ninety percent broken, a run history full of green checkmarks, and four hypotheses I had knocked down in under half an hour. I was slightly stuck. I said as much on our shared Slack, which I think is the honest thing to do when you are stuck.

The clue I almost missed

I went back to a Completed run and this time actually read the values the condition step was checking against.

The condition was written as "Customer tags is empty or does not exist" - the workflow was supposed to apply the first_purchase tag only when the customer had no other tags yet, on the theory that a customer with no tags is by definition a first-time buyer. That logic is fine. Except Flow evaluates it wrong.

Shopify Support classified it in October 2024 as "a limitation of the Shopify Flow app" and promised future improvements. The bug: when a customer genuinely has no tags, the "Tags is empty or does not exist" condition returns False. Flow takes the False branch. The tag never gets applied. The Klaviyo property never gets set. And because the workflow is designed with valid branches on both True and False, the run completes without any internal error, and every row in Run history shows green.

This is one of the ugliest shopify flow silent failures in the catalogue, because it does not fail on your test customer, who has tags. It fails on every genuinely new buyer, who does not. The one type of customer the workflow was built to catch is the one type it silently misses.

The workaround, contributed by a community member in March 2026, is to invert the branches: check for the presence of a specific tag, then swap the True and False paths. I did that, redeployed, and their first-purchase count came back within a day.

What I now check on any Flow audit

I keep a checklist. In order:

Read Run history status for a full week per workflow. Green everywhere is not proof of anything.
For each Completed run I sample, open it and confirm the downstream effect actually happened. Was the tag applied to the customer? Did the email get delivered? Is the Klaviyo property present on the profile? If the answer is no, ignore what Flow told me.
If the workflow uses "Tags is empty" or any list-operator condition (the "does not include" trap is a cousin bug, documented by paul_n in a 2023 forum thread), invert the branches or rewrite the operator. Do not wait for Shopify to fix it.
If the workflow reads customerJourneySummary data at Order paid time, insert a five-minute wait step before the read.
If the workflow uses any third-party connector (Slack, Klaviyo, the ones with OAuth under the hood), plan on manually disconnecting and reconnecting it every quarter. Slack in particular is limited to a single connected user per store, and any change to that user's workspace can drop the connection without alerting anyone.
Count active workflows on the same trigger. Over ten sharing "Order paid" starts creating a compounding performance load and Shopify's own docs flag it as a performance wall.
Count total workflows in the store (active plus inactive). The hard cap is a thousand. There is no counter in the Flow dashboard. You discover the cap when a merchant's team asks "why can't I make a new one?" and you go look.

If you are running Flow for anything customer-facing and you would like a second pair of eyes on the run history you have been trusting, that is what help1's expert chat is set up for, and the first fifteen minutes are free. I would rather spend that time looking at your Flow than have you find out about a broken automation from a customer support ticket.

What Shopify's own tools do not tell you

Two more things I keep having to say out loud, because the merchants I talk to keep being surprised by them.

The Shopify status page is not a reliable early-warning signal for Flow-specific incidents. A February 2025 infrastructure event that took Flow triggers offline across multiple stores did not appear on status.shopify.com for hours, and an August 2025 r/shopify report explicitly says "No Outages" was showing during the incident. If your flows stop firing and status says everything is fine, do not close the browser tab. Open a support ticket and check the community forums for other reports. Under-reported outages are another slice of shopify flow silent failures I have watched play out this year.

The "Send invoice" email action, the one Shopify prompts you to use for balance-owed workflows, silently fails on paid orders with "Ran into transient error: GraphQL Response User Errors: 'No outstanding balance exist.'" The workflow shows as Running forever. If you have automations that use it, make sure the trigger condition guarantees the order has an outstanding balance before the action fires. This one has bitten enough merchants that the community's recommended workaround is "use Klaviyo for the email instead", which is the sort of workaround that tells you something about how load-bearing Flow really is in a stack that was designed to replace Scripts inside.

I am not saying Flow is bad. I use it. I still recommend it for the small, well-scoped automations it is good at. But if you built anything critical on it and then walked away because the dashboard was green, you and I should probably have a look at it together. Related reading, if you want the parallel Scripts story: what I have been finding since Shopify shipping Scripts went dark is the same pattern of quiet failure on a different surface.

One question to answer before you close this tab

If a Shopify Flow of yours has been showing all-Completed for the last month, and you had to bet, right now, on whether the intended downstream effect has actually been happening on every run, what would you bet? Not what the dashboard says. What you actually believe.

If you are less than certain, that is the workflow to open Run history on today, click into three sample runs, and verify against the customer or order record itself. The dashboard can wait.