Three outages this month had nothing to do with the team that got paged. GitHub Copilot degraded because an AI model provider had a bad afternoon. Shopify checkouts broke because Klarna did. A production Postgres instance went dark because of an unannounced platform issue on Supabase's side. None of these teams caused their own outage — but each one had to explain it anyway, and the interesting differences are in how each one found out. One caught it through automated monitoring within minutes. One could only point customers at someone else's status page. One had a health check that said everything was fine while the database was unreachable. Same instinct as Roundup #3: read past the headline, and look at what each team actually knew, and when.
GitHub Copilot: The Vendor Broke, the Monitoring Worked
At 13:22 UTC on September 3, GitHub's automated monitoring flagged degraded performance for Copilot's AI model providers. Within three minutes GitHub had scoped it precisely: "experiencing degraded availability for the Grok 4.6 model in Copilot Chat, VS Code and other Copilot products," then two minutes later, "the Grok 4.5 model has degraded availability as well." The cause sat entirely outside GitHub's infrastructure — an issue with the upstream model provider serving Grok. There was nothing for GitHub's own engineers to fix; the incident report says only that they were "working with them to resolve the issue." At 17:11 UTC, three hours and forty-nine minutes after it started, the provider's own mitigation cleared it: "issues with our upstream model provider have been resolved, and Grok models are once again available."
What's worth noticing here is what didn't go wrong. GitHub's monitoring caught the degradation immediately, scoped it to the exact affected models within minutes, and kept publishing honest updates through a nearly four-hour window where the honest answer was "we're waiting on someone else." That's a harder discipline than it sounds — the instinct during a vendor-caused outage is either to go quiet (nothing to report) or to over-explain (make it sound like you're doing more than waiting). GitHub did neither.
https://www.githubstatus.com/incidents/ktdr5t0xwnhp
Shopify Checkout: When the Fix Isn't Yours to Ship
On September 2, Shopify's status page opened an incident at 3:52pm: "an issue with Klarna, which may be affecting checkouts using this gateway." Twenty minutes later, with the problem still live, Shopify's update told merchants to go look somewhere else entirely: "refer to Klarna's status page for their latest updates." By 4:52pm Shopify had narrowed it down — "the problem with Klarna payment gateway as well as related integrations" — and was coordinating with Klarna directly, but the checkout flow for any merchant using Klarna stayed degraded through the afternoon while the fix sat with a company Shopify doesn't control.
This is the least comfortable version of a vendor outage: it's customer-facing, it's revenue-facing, and the affected company's own status page can only narrate someone else's incident. Shopify did the right things available to it — fast identification, honest scoping, a working relationship with the vendor — but "refer to Klarna's status page" is a sentence that only works if merchants already know Klarna sits underneath their checkout at all. A payment method integrated three product layers up doesn't usually get flagged as a dependency worth watching until the afternoon it takes checkout down with it.
https://pulsetic.com/status/shopify/incidents/6916/
Supabase: The Health Check That Lied
On September 15, a production Postgres instance on Supabase went unreachable at 14:16:06Z. Nobody paged on it — not because nothing was wrong, but because the uptime monitor was checking the wrong thing. The team's own postmortem is blunt about it: `/health returns HTTP 200 status: ok while supabase: error`. The health endpoint kept reporting success because it was checking that the application process was alive, not that it could actually reach the database. The outage ran undetected until someone noticed the app failing manually; an operator-approved restart through Supabase's Management API finally restored the connection at 15:45:16Z, one hour and twenty-nine minutes after it started. The platform-side root cause was never fully determined.
The fix that came out of it is the real lesson: the team widened an existing monitoring ticket to P1, specifically to make the health check "verify actual database connectivity, not just HTTP 200 responses," and added a deploy-time gate that now fails outright unless the app can confirm `supabase: "connected"` before shipping. That's the same trap Monday's issue described from the alerting side — a check that answers "is the process running" gets treated as though it answered "is the system working," and the gap between those two questions is exactly where an outage hides until a human finds it by accident.
https://github.com/jikig-ai/soleur/pull/8215
The pattern across all three
None of these three teams broke their own system. GitHub's Grok models failed because of xAI's infrastructure. Shopify's checkout failed because of Klarna's. Supabase's platform had a problem nobody outside Supabase could see coming. What actually varied wasn't the failure — it was each team's visibility into it. GitHub's monitoring told them exactly what was down within minutes. Shopify's monitoring told them the truth but the truth depended on a vendor's own status page. Supabase's customer had monitoring that told them a comforting lie.
A dependency you don't control is not optional to monitor just because you can't fix it. You can't patch Klarna's gateway or restart xAI's model servers, but you can decide whether your own health check verifies the thing that's actually load-bearing, or just the thing that's easiest to check. The GitHub and Supabase incidents ran for comparable lengths of time — under two hours each — but one team knew what was happening from minute one, and the other found out by accident. That gap is entirely a monitoring design choice, made long before either outage started.