Three outages in the past week, at Microsoft Azure, Slack and GitHub, broke in the gap between two systems that each worked on their own. At Azure, two changes Microsoft itself calls unrelated hit the same regions at the same time. At Slack, a third-party app stuck in a loop tripped a sending limit, and the limit blocked free-plan workspaces from posting. At GitHub, the network link between an on-premises data center and cloud-hosted databases partly failed. None of the three started with a component that was simply broken.
Azure: Two Unrelated Changes in the Same Regions
From 20:30 UTC on September 30 to 02:15 UTC on October 1, some customers using Azure's gateway services in multiple regions saw degraded or interrupted network connectivity, gateways failing to load in the portal, and failed or delayed network management operations. The affected products are most of the ways an enterprise network gets into Azure: ExpressRoute Gateway, VPN Gateway, Azure Firewall, Application Gateway and its WAF, and Azure VMware Solution. Early coverage put the footprint at 18 regions, but Microsoft has since corrected the region list in its status entry, which now names France Central, North Europe, Southeast Asia, UK South and UK West as the last to recover.
Microsoft's preliminary review, under tracking ID 7Q30-010, says "a recent change to a regional gateway management service triggered a higher-than-expected load when an unrelated operating system servicing maintenance proceeded gradually through multiple regions." The gateway service would normally autoscale, but the extra work also raised demand on the services it depends on, and that stopped it from scaling. Engineers paused the OS servicing and reverted the gateway-manager change. A full post-incident review is due within 14 days.
Microsoft's own timeline shows how long a seam takes to see. Impact began at 20:30. Investigation started at 21:29, focused on ExpressRoute Gateway in UK South. At 22:27 the team realized several regions were involved, and at 23:05 it found "a correlation with operating system servicing activity" and paused it. That's two and a half hours from first impact to linking the two changes.
The word doing the work in Microsoft's explanation is "unrelated." A few weeks ago I wrote about the opposite trap, where on-call engineers assume incidents that show up together must share a cause. Here, two changes that had nothing to do with each other really did combine. The OS servicing was moving region by region, which is the careful way to do it. But a staged rollout tests a change against the system as it stood when the rollout began. It has no way to test against a separate change that is also still in flight, and when the damage only appears where the two overlap, going region by region just carries the overlap into more regions.
Recovery, at least, was the straightforward kind. Reverting a service change is the case where rollback does what you expect, which Monday's issue argued is less common than teams assume.
https://azure.status.microsoft/en-us/status/history/?trackingId=7Q30-010
Slack: Someone Else's App Hit the Limit
At 12:39 UTC on October 1, Slack reported that "some customers on our free plan are experiencing message-sending limit blocks in an unusual spike pattern." Seventeen minutes later it had the cause: "a third-party app is stuck in a loop that has triggered billions of messages." Later updates added that "a feature toggle ramp-up caused an app integration to repeatedly post messages in a processing loop," and that this "pushed free plan customers over the message volume threshold, triggering the sending block."
The limit did its job. It saw an enormous spike and stopped the sending, but the people it stopped were free-plan users trying to post ordinary messages. Slack's updates don't say whose feature toggle it was, or whether the blocked workspaces were only the ones with that app installed, so I won't guess at either. The timeline is what stands out. Slack named the cause 17 minutes in, yet it didn't announce a potential fix until around 18:52 UTC, and sending wasn't restored for every affected workspace until just after 19:00, six hours and 23 minutes after the first report. Knowing exactly what was wrong didn't come with a quick way to lift the block.
The seam here runs between a platform and the integrations people build on it. Rate limits and abuse thresholds are usually designed around one kind of traffic. If an integration's messages count toward the same threshold that guards your users, a bug in someone else's code becomes your users' outage. Roundup #4 looked at teams paged for outages that started at a vendor. This one runs the other way: the platform got hurt by something built on top of it.
https://slack-status.com/2026-10-01
GitHub Actions: The Link Between the Old Data Center and the Cloud
On October 5, between 18:48 and 22:49 UTC, GitHub Actions and its hosted runners degraded badly. In the worst 90 minutes, 47.0% of workflow runs on GitHub-hosted runners failed and 71.9% of hosted jobs didn't start within five minutes. Repository lists, billing and licensing pages, and some Copilot features also threw intermittent errors. Self-hosted runners were not affected.
GitHub's summary puts the cause down to "a partial networking failure that disrupted connectivity between one of our on-premises datacenter regions and a subset of cloud-hosted regional database and storage services." It mitigated by moving database and storage traffic to healthy regions and endpoints and adding compute capacity, and says it is working with its cloud provider on the network failure itself.
That sentence describes a company partway through a move. GitHub has been migrating off its own data centers onto Azure, and for as long as a migration like that runs, some of the system lives in the old place and some in the new, with a network path between them that the whole system now leans on. Both ends can be healthy while the path between them isn't. Four days earlier, GitHub had a smaller Actions incident it attributed to "throttling within an upstream Azure dependency." Neither incident means the migration is a mistake. Both show what the middle of one looks like from outside: new dependencies on the hot path, each with its own way to fail.
https://www.githubstatus.com/incidents/c11dc9nb1zdq
Who Owns the Seam?
Ask which team owned each of these failures and the answer gets awkward. At Azure, the gateway-manager change and the OS servicing were separate pieces of work that Microsoft describes as unrelated. The looping app belonged to someone outside Slack entirely, while the limit it tripped belonged to Slack. At GitHub, the failing path ran between an environment being retired and one being adopted. Every component had an owner. The connections between them are the parts nobody draws a dashboard around.
Three checks follow, and none of them is expensive:
Before you start a rollout, find out what else is rolling out to the same regions or hosts that week. A shared change calendar is low-tech, but it's the only thing likely to show two "unrelated" changes heading for the same place.
Look at what your protective limits actually count. If an integration, a batch job or a retrying client can push the same counter your users depend on, decide ahead of time who gets blocked when it trips and how quickly you can lift it.
If you're mid-migration, give the links between the old and new environments an owner, an SLO and their own alerts. They're meant to be temporary, and temporary infrastructure tends to get none of those.
Microsoft's full review of the gateway incident is due within two weeks. If it says more about how the two changes met, it'll show up in a future Roundup.