Zapier's Azure DevOps connections broke for 1h 9m on 28 September after an OAuth client secret expired on the provider's side. If any of your Zaps use that connection, the fault sat with Zapier, not your setup.
Started
12:13 UTC
Duration
Lasted 1h 9m
Source
IsDown
Next time
Zapier is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: Zaps, Instant Triggers, Polling Triggers
What happened?
Zapier logged one incident on 28 September, starting at 12:13 UTC and lasting 1h 9m. The listed components were Zaps, Instant Triggers and Polling Triggers, three entries for what was really one cause. Zapier's own first update named the problem precisely: an expired OAuth client secret on the Azure DevOps connection, error code AADSTS7000222. That is a credential issue on the authentication handshake between Zapier and Azure DevOps, not a general platform failure, and Zapier said as much: "Only Zaps using the Azure DevOps connection are affected." At 12:40 UTC, 27 minutes after the first post, Zapier reported the secret had been resolved, with a note that if a connection still showed as expired you might need to manually test it to restore it. That is the full record, two updates and nothing further filed since. No post-mortem has been published explaining why the secret expired or whether it was renewed early enough to avoid repeats. No user reports were filed during the window, which fits a narrow, single-connector fault rather than something that would have flooded support queues. For context, Zapier has logged 23 incidents in the past 90 days with a median duration of 3 hours 19 minutes, so this one resolved faster than Zapier's own recent average.
Learning
This incident sat entirely on Zapier's side of the connection, in the credential exchange with Azure DevOps, which is not something an external check against your own product would ever see. UptimeRobot's 30 day data for Zapier shows 5 incidents, all resolved, with a median duration of 3h 3m, a figure built from watching Zapier's status and endpoints directly rather than guessing from your own app's symptoms. If your product only pings its own health endpoint, an expired OAuth secret inside a third party integration layer will never show up there, your endpoint stays green while the Zap quietly fails to fire. That is the general shape of this kind of fault: the breakage happens one layer removed from anything you control or monitor yourself, in a connector's authentication rather than in your code. Watching your own endpoints tells you your product is up, it does not tell you whether the automation plumbing behind it is working. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
