What Happens to Your Automations During a Zapier, Make, or Power Automate Outage?

Detailed Explanation

Every "automation failing" problem covered elsewhere in this cluster assumes the platform itself is running normally and something specific broke — a credential expired, a field got renamed, an error went unnoticed. This page covers a different situation: the vendor's own infrastructure goes down or degrades. It's a known, publicly tracked event with a status page and (usually) a postmortem, not a silent one — but "we know it happened" and "we know exactly what it did to our data" are two different things, and the gap between them is where businesses get caught out.

The single most important variable in what happens next isn't which platform you use — it's what kind of trigger started the flow.

Scheduled and polling triggers are generally forgiving. A flow that runs on a timer, or one that periodically checks a source for new records (a spreadsheet, an inbox, a database view), doesn't need anything to happen at the exact moment an event occurs. If the platform is down when a scheduled run was due, the next successful run — whether that's an automatic retry or simply the next scheduled interval — can typically find and process whatever accumulated in the meantime. This is the closest thing to "runs will catch up automatically" being a safe assumption, and it's the main reason that phrase gets repeated as if it applied universally.

Real-time, webhook-based triggers are the riskier case. A webhook is the sending app (your CRM, your form tool, your payment processor) proactively pushing an event to the automation platform the instant it happens, rather than the platform going and checking periodically. If the automation platform's webhook receiver is down when that push arrives, what happens next is entirely up to the sending app, not the automation platform — some apps retry failed webhook deliveries for a period (minutes to a few days, depending on the vendor), and some make no retry attempt at all, meaning a webhook that arrives during downtime is simply gone. This is the scenario "it'll catch up automatically" fails silently on: the automation platform recovers, everything looks normal again, and nobody notices that a handful of events during the outage window were never delivered in the first place.

How Each Platform Actually Behaves

Zapier distinguishes between the trigger side and the action side of a Zap during a detected outage. On the action or search side, a step affected by an outage shows a "playing" status in Zap History and is retried automatically — Zapier's own documentation describes retrying for a period tied to the incident, with a defined retry limit after which the step is attempted regardless of the connected app's reported status, so it doesn't hold data indefinitely. On the trigger side, Zapier's polling deliberately backs off during a detected API outage (skipping most poll attempts rather than hammering a struggling API) and ramps back up once health checks pass, then works through what it finds — subject to each app's pagination limits, so an outage that runs long enough can still mean the very oldest missed records fall outside what a single catch-up poll retrieves.

Make queues scenario executions that were due to run during an outage and generally processes that queue once service is restored, particularly for scheduled and polling-based scenarios. The complication specific to Make is less about the recovery mechanism and more about visibility: third-party monitoring and user reports have documented cases where Make's own status page continued to show "all systems operational" during periods when users were experiencing real disruption, which matters directly for the "where do I check" question this page exists to answer — a clean status page is a useful signal, not a certainty.

Power Automate inherits its outage behavior partly from the specific Microsoft 365 or Dataverse connector each flow depends on, not just from Power Automate itself. A flow can look broken because Exchange, SharePoint, or another connected service is degraded rather than Power Automate's own infrastructure. Check service health for the specific product involved (Power Platform admin center or the Microsoft 365 admin center's Service health page) rather than assuming Power Automate is the source. Whether a missed event-based trigger catches up afterward depends on the connector's own re-delivery behavior, which varies by connector and isn't something Power Automate guarantees uniformly.

n8n is the one case where "vendor outage" doesn't automatically apply the same way. On n8n Cloud, you're in the same position as a Zapier or Make customer — dependent on n8n's infrastructure and its own status communication. Self-hosted n8n removes that dependency entirely and replaces it with a different one: the instance's uptime is now your business's responsibility (or your hosting provider's), not a vendor's. That's a genuine advantage during a third-party platform's outage — a self-hosted instance keeps running regardless of what's happening to Zapier or Make — but it means there's no vendor status page to check when something does go wrong; monitoring the instance itself becomes entirely your job. See Zapier vs Make vs n8n vs Power Automate for how that trade-off fits into choosing a platform in the first place.

Where to Check Platform Status

• Zapier — status.zapier.com for current incidents, plus Zap History for the run-level detail on any specific affected Zap.
• Make — status.make.com, cross-checked against the community forum or support if a scenario looks broken but the status page reads clean.
• Power Automate — service health in the Power Platform admin center or the Microsoft 365 admin center, which is more specific than Power Automate's own status alone since a flow can be affected by an upstream Microsoft 365 service outage.
• n8n Cloud — n8n's own status communications; self-hosted n8n has no vendor status page to check, since the infrastructure is yours — this is where your own uptime monitoring on the instance itself matters.

Bookmarking these — or better, subscribing to each one's status updates — is a five-minute setup that saves real diagnostic time the next time a flow looks broken and the actual cause is upstream, not something in your workflow.

Business Continuity for Mission-Critical Flows

Most business automations can absorb an hour or two of vendor downtime without real consequence — a delayed internal notification or a report that runs a few hours late rarely costs anything. A small number of flows are different: anything handling time-sensitive customer communication, payment processing, or a compliance-relevant deadline can turn a vendor's outage into your business's problem the moment "the platform will catch up" turns out not to apply to that flow's trigger type.

For the flows that genuinely qualify as mission-critical, a brief continuity plan is worth having before an outage happens, not during one:

• Know which of your flows are actually critical. Not every automation needs a continuity plan — see how do you prevent automation sprawl as your business adds more workflows for keeping a register that flags which flows matter enough to plan around, rather than treating all of them as equally important (or equally disposable).
• Know the trigger type for each critical flow. A scheduled flow's continuity risk during an outage is low; a webhook-driven flow's is higher, for the reasons above — this single fact should drive how much continuity planning a given flow actually needs.
• Have a manual fallback that someone actually knows how to execute. For a genuinely critical flow, write down the manual version of the process (who does what, using which systems, by hand) so it isn't being improvised for the first time during a live outage.
• Decide in advance who monitors status pages during a suspected outage, so that during an actual incident, checking status.zapier.com or the Microsoft 365 admin center is someone's specific, known job rather than something three people assume someone else is doing.

This overlaps with the broader risk named in why do automation projects fail: over-reliance on a single vendor's continuous availability, with no fallback plan, is a strategic risk that sits above any individual flow's technical design.

Things to Consider

• This is a different failure mode from a flow quietly breaking on its own. See how do you stop an automation from failing silently for the far more common case — a single flow degrading because of an expired credential or a renamed field while the platform itself runs normally. A vendor outage is a known, tracked event affecting many customers at once; a silent failure is invisible and affects only you. Both need monitoring, but they need different monitoring.
• A status page going green doesn't mean your specific data is fully recovered. Especially for webhook-driven flows, "the platform is back up" and "every event that occurred during the outage was successfully delivered" are separate claims — spot-check a critical flow's recent run history after any outage you were aware of, rather than assuming recovery was complete just because the platform reports as healthy again.
• Retry and polling behavior is a genuine tool capability, and tool capabilities change. The specific retry counts and polling backoff windows described above reflect each vendor's documented behavior as of mid-2026; verify against current official documentation if the exact mechanics matter for a specific critical flow, rather than treating this page as a permanent technical reference.
• Self-hosting n8n trades vendor-outage risk for your-own-uptime risk. It isn't a strict upgrade — during a widespread SaaS outage a self-hosted instance keeps working, but it also means nobody but you is responsible for noticing and fixing an outage on your own infrastructure.

Common Mistakes

• Assuming "runs will catch up automatically" applies to every trigger type. It's a reasonably safe assumption for scheduled and polling triggers, and an unsafe one for real-time webhook triggers unless you've specifically confirmed the sending app retries failed deliveries.
• Debugging your own workflow logic first, instead of checking platform status first. A flow that "just stopped working" during a known vendor incident isn't a configuration problem — checking the relevant status page takes thirty seconds and can save an hour of unnecessary troubleshooting.
• Treating a green status page as proof nothing was missed. Particularly on platforms where the status page has been shown to lag real disruption, a clean status page is a useful data point, not a guarantee that every event during a suspected incident window was captured.
• Having no continuity plan for the one or two flows where an outage genuinely matters. Most flows don't need one; the mistake is not identifying in advance which few actually do, and then improvising a manual fallback for a customer-facing or financial process during a live incident.
• Confusing an upstream connected-service outage with the automation platform being down. Especially on Power Automate, a degraded Exchange or SharePoint service can make a flow look broken when the automation platform itself is fine — check the specific connected service's health, not just the automation platform's.