Shopify Webhook Not Working: Where the Log Is by Route

Orders still land in your Shopify admin, but the other side has gone quiet: the spreadsheet stopped filling on Tuesday, the Zap that posts sales into your accounting shows no runs, or the webhook you set up is no longer in Settings > Notifications > Webhooks — and nothing told you.

Where the evidence is, and what you can still recover, depends on which of four routes sent the data. Only three of them keep a log.

Which Route Sent the Data That Stopped?

Name the route first — the log and the replay both follow from it. Two minutes in your admin:

• Listed in Settings > Notifications > Webhooks, or it used to be: an admin webhook.
• A workflow in Apps > Flow with a Send HTTP request step: Shopify Flow.
• A Shopify trigger in Zapier, Make or n8n: a connector.
• The destination belongs to an app you installed, or the store owner got a failure email from Shopify: the app owns the subscription.

Read September 22, 2026: Shopify's Flow monitoring page, Creating webhooks, shopify.dev's webhook troubleshooting page, and the Zapier, Make and n8n documentation, including Make's plan pricing table.

Where Is the Log for a Webhook You Typed Into Settings?

No page we have found publishes a delivery log or history screen for a webhook typed into Settings (the box below lists what was read); only the receiving end knows whether an event arrived.

Shopify's Creating webhooks page states that if the destination repeatedly returns a non-200 status response, the subscription is automatically deleted from your admin — so a webhook that vanished from the list is the documented end of failures you never saw.

And the failure email is a route signal, not a safety net:

The repair is to recreate the webhook with the same event and URL, then use Send test and verify at that URL that the notification arrived. That proves the address answers now; it does not replay what was lost.

Shopify Flow: The Run Log and the Retry Button

If the connection is a workflow, you have a log in the admin and a button that runs the failed job again.

Finding the Run That Failed

Flow stores every execution as a workflow run — in its own words, a log of what happened — listed under Apps > Flow > Recent runs.

Nine filters narrow the list, and three do the diagnostic work: Errors isolates failed runs, Start time finds the day the data stopped, and Retry status shows whether someone already retried a run.

Move quickly. Shopify's monitoring page states that workflow runs are stored for 14 days after a run completes, and are then removed from the system.

Retrying One Run or a Whole Batch

The manual-retry page describes two moves: Retry run on the run details page, or Retry runs from the workflow summary after selecting every run the problem hit. The page lists five considerations:

• The run has finished — not still running or waiting.
• The workflow is active.
• Its trigger matches the one the original run used.
• The retry reuses the original trigger data.
• Get data actions fetch fresh data, so conditions and actions run on today's values.

Beyond those five, the page read on September 22, 2026 states no maximum number of runs per retry and no cut-off by age.

If the HTTP step is what failed, the rule sits in the action: Flow waits a maximum of 30 seconds for a response code, then retries later, and on a 4XX, 5XX or 429 it does what the action was set to do — Retry for up to 24 hours, Fail the run, or Ignore the error. The action is available only on the Plus, Advanced and Grow plans.

Zapier, Make and n8n: History and Replay

With a connector in between, Shopify's part ends when the event is sent; whether it arrived, and whether it can run again, is answered in the connector's own account.

Zapier: Replay by Hand, or Let Autoreplay Do It

Zapier's Zap history guarantees a maximum of 60 days of Zap run data, displaying up to 10,000 runs. No Zapier page we have found says how often polling triggers check (see the box above), so an empty history does not prove Shopify sent nothing. On the Free plan manual replay covers errored runs only; autoreplay of errored runs works only on the Professional, Team and Enterprise plans, switched on account-wide by an account super admin or owner, and any member can enable it on a Zap they own (how Zap history and Autoreplay differ).

Make: Incomplete Executions Are Off by Default

Make's History tab shows each run, but after a failure the place to look is Incomplete executions, a safety net that stores an unfinished run instead of losing the data. It is disabled by default: Store incomplete executions in the scenario settings turns it on, and an empty tab usually means it never was.

n8n: Retry With the Original or the Current Workflow

n8n lists runs on the Overview page's Executions tab. Retry with original workflow repeats a failed run unchanged; Retry with currently saved workflow runs your edited version on the same data. A list emptier than expected usually points to the workflow's save settings or, on self-hosted instances only, to default pruning of executions older than 336 hours, about 14 days, or beyond 10,000 of them. On n8n Cloud the ceiling comes with the plan instead: Start and Starter save at most 2,500 executions with 7 days of retention, Pro 25,000 with 30 days, and Enterprise 50,000 with no time limit.

When an App Owns the Webhook: What Your Developer Sees

A failure email to the store owner — sent only for App Store or custom app webhooks — puts you here, and the subscription belongs to the app, not to your admin.

Your developer sees two screens you do not: a Logs page of individual deliveries, filterable by topic, status and shop, and a Monitoring page (Dev Dashboard > Apps > the app > Monitoring) with delivery counts and response times — each over the past 7 days.

Behind those screens, Shopify retries failed webhook calls up to eight times in a four-hour period and removes the subscription if failures persist, while its metrics table separately describes removal after multiple failures in a 24-hour period. A delivery fails if the app does not respond within five seconds.

Nor does Shopify promise delivery:

So the documented fix is not a resend but a reconciliation job — the loop a custom integration is built around, as the ERP guide shows. Send the developer:

• your myshopify.com domain and the event that stopped;
• the window of silence, and whether the owner got an email;
• two questions: is the subscription active, and can a reconciliation job refill the gap?

Can You Still Get the Orders That Never Arrived?

For a webhook created in the admin, no page we have found describes resending or replaying an event already delivered or lost (the box above lists what was read).

The Export orders screen has an Orders by date option, and the window's size decides delivery: up to 50 orders or the current page download to your device, while more than 51 orders or any export by date is emailed to you and the store owner.

Which Recovery Move Is Yours?

The table at the top answers by route; this one adds the elapsed time and what your tool still shows.

Recover the Gap, Then Re-Arm the Connection

Repair comes before replay: a retry into a broken endpoint fails again, and orders placed between an export and the repair land nowhere. In Flow, a retry needs the workflow active and the original trigger unchanged.

For the setup side of the last step, our webhooks guide covers how to notice a dead subscription before your bookkeeper does.

The Bottom Line

A stopped webhook is a route you have not identified yet. Name it, then repair the connection, retry what is still listed and rebuild the rest from your orders.

Frequently Asked Questions