If an Automation Breaks at 2am, Who Is Actually on the Hook?

Detailed Explanation

Ask most businesses running automation who's responsible when it breaks, and the honest answer is usually "we've never actually worked that out." The question rarely comes up until the moment it matters — and by then, whoever built the workflow may not be reachable, and the failure may have been silently producing wrong results for days before anyone noticed.

The uncomfortable finding, once you look at what actually causes automation failures, is that the platform going down is one of the less common causes. A review of the 25 most recent incidents logged on Zapier's own public status page — spanning roughly 12 weeks — found that 12 of the 25 named a specific third-party application, not Zapier itself, as the source: a connected CRM, a spreadsheet app, a messaging platform, an HR system, a lead-capture tool. Two of these ran for the better part of a working week before being resolved, with data silently failing to sync rather than the workflow erroring out visibly. This is illustrative of a pattern rather than a fixed statistic — the exact ratio will shift over time — but the underlying point holds regardless of the specific figures on any given day: the platform's own status page is not a reliable signal for whether your automation is actually working.

Why "the Platform Is Up" Doesn't Answer the Question

Uptime SLAs, where they exist at all for small-business automation contracts, typically cover the platform vendor's own infrastructure. They say nothing about:

• A connected app changing its API without warning, in a way that breaks field mapping or authentication.
• A connected app going down independently of the automation platform, while the platform itself reports no issue.
• Silent data problems — a workflow that keeps running without erroring, but starts producing incomplete or wrong output because an upstream field, format, or permission changed.
• Rate limits or quota changes on a connected service that cause intermittent, hard-to-diagnose failures rather than a clean outage.

None of these show up as "the automation platform is down." All of them can mean your business stops getting leads, stops sending invoices, or stops updating records — for hours or days — while every dashboard shows green.

The Questions Worth Answering Before You Sign, Not After

If you're paying someone to build or run automation for your business, ask these before the contract is signed:

1. What counts as an incident that gets reported to us, and how is it detected? A vague "we monitor everything" is not an answer — ask what specifically triggers a notification, and whether that includes silent failures (a workflow that runs without erroring but stops producing correct output) as well as outright crashes.
2. What's the actual notification timeframe? Not "as soon as possible" — a stated number, even if it's a business-hours-only commitment. If the answer is vague, assume the real answer is "whenever someone happens to notice."
3. Who diagnoses the cause, and what happens if it's a third-party app's fault rather than the automation itself? A provider who only takes responsibility for their own build, and treats a connected app's outage as entirely your problem to escalate, is not offering the protection the retainer implies.
4. What's the remediation commitment once the cause is known? Not just "we'll fix it" — a stated priority level and expected timeframe, even a rough one, turns a vague promise into something you can actually hold someone to.

If none of these have a written answer, the automation is effectively unsupported, regardless of what the sales conversation implied.

What "Being on the Hook" Actually Means in Practice

For a small or mid-sized business, "who's on the hook" usually resolves to one of three answers, and it's worth knowing honestly which one applies to your setup:

• Nobody, by default. If you built it yourself with no formal support arrangement, or your provider's engagement ended at "handover," you are the one who finds out something broke — often from a customer complaint or a missing invoice, not from a monitoring alert.
• The provider, but only for what they built. Many automation agencies and freelancers will fix bugs in their own workflow logic but explicitly exclude third-party app changes, API deprecations, or connected-service outages from what they'll proactively watch for or fix under a fixed retainer.
• The provider, comprehensively, as an explicit part of the service. This is the meaningfully different tier — active monitoring for silent failures, a stated response time, and responsibility for diagnosing whether the cause sits with the automation, a connected app, or something else, before handing the problem back to you.

Most sales conversations imply the third tier while the contract, if one exists, only actually commits to the second or first. Reading the actual commitment, not the pitch, is the only way to know which one you have.

Things to Consider

• This is a different question from the technical mechanics of an outage. What happens to your automations during a Zapier, Make, or Power Automate outage covers what actually happens to queued and real-time triggers when a platform goes down; this page covers who is contractually and organisationally responsible for noticing, diagnosing, and fixing any failure — outage or otherwise.
• This is a different question from vetting a consultant before you hire them. What should you ask an automation consultant before hiring them covers pre-engagement due diligence; this page covers the ongoing run contract once the automation is live.
• A small, occasional failure rate is normal — an unmonitored one is not. No automation setup is failure-proof; the question is whether failures are caught quickly by someone with a reason to fix them, not whether they happen at all.
• Ownership and support responsibility are related but separate questions. Knowing who owns the workflows, accounts and API keys when the project ends tells you who can fix something; this page is about who is actually watching for the problem in the first place.
• Vendor-side changes are a recurring, not one-off, source of breakage. See what happens to your automations when a vendor changes or retires its API for how often this specific failure mode occurs and what a provider watching for it in advance actually looks like.

Common Mistakes

• Assuming the automation platform's published uptime is a proxy for "my automation works." As the incident pattern above shows, most real failures aren't the platform being down — they're a connected app misbehaving while the platform itself reports normal.
• Signing a support arrangement without asking what "support" actually covers. A retainer that only covers the provider's own code, and excludes third-party app changes entirely, leaves you exposed to the majority of real-world failure causes.
• Waiting to find out who's responsible until something has already broken. By that point, the answer is whatever the contract happens to say — or nothing, if there is no contract — rather than something you negotiated with any leverage.
• Treating "we'll fix it eventually" as equivalent to a stated response time. A commitment with no timeframe attached is not a commitment a business can actually plan around.