An Inngest outage on October 20, 2026 hit event ingestion, function scheduling, and execution twice in one day, and according to Inngest's own incident report, the second failure mode made the first one worse: the services that needed to restart couldn't come back online without the exact database connection the outage had already taken away.
Jump to what we checked in our own restart paths if any of your own services require a healthy dependency just to finish booting.
Two Short Windows, One Shared Cause
Inngest's status page and incident report describe two separate disruption windows on October 20: 13:00 to 13:15 UTC and 15:20 to 15:35 UTC. During both, event submissions could fail or time out, function scheduling was delayed, and execution and checkpoint requests ran slower than usual, with full event ingestion unavailable during parts of each window.
The company's own report attributes both windows to the same underlying problem: a connectivity disruption between Inngest's application infrastructure and its database. Database requests stalled, and every database-dependent operation, scheduling, execution, checkpointing, slowed down with them.
The Detail That Turned a Blip Into Two Outages
Here's the part worth isolating. During the disruption, Inngest's event ingestion services ran out of available memory and restarted on their own, which sounds like exactly what you'd want a resilient system to do automatically. The problem is what came next: those services' startup process also required a successful database connection to complete.
Connectivity was still impaired. So the restarted services couldn't finish booting, and event ingestion stayed down for as long as the underlying database connectivity problem lasted, even though the individual service instances had already tried to self-heal. Inngest's own root-cause writeup names this directly as two separate resilience gaps that compounded each other: memory exhaustion under load, and a recovery process that depended on the exact resource the incident had taken offline.
Why a Restart Isn't Automatically a Recovery
A service that restarts when it runs out of memory is doing something sensible under normal conditions. The same restart becomes a liability the moment its startup sequence has a hard dependency on something that might be unavailable for the same underlying reason the service needed to restart in the first place.
Inngest's incident didn't need a new, unrelated failure to get worse. It needed the recovery path for one failure to quietly share a dependency with the failure itself, and once that was true, the restart stopped being self-healing and started being a second outage layered on top of the first.
What We Checked in Our Own Restart Paths
We went through every service at Krova Cloud that restarts automatically on an out-of-memory condition and checked whether its startup sequence has a hard dependency on a resource that could plausibly be unavailable for the same reason the restart was triggered.
We found one internal job-scheduling service whose startup health check required a successful connection to the same database cluster it processes jobs against, the same shape of dependency that compounded Inngest's incident. We're adding a degraded-start mode that lets the service come up and queue locally if that specific connection isn't available yet, rather than blocking startup on it entirely.
What to Check in Your Own Infrastructure
- List every service that auto-restarts on resource exhaustion, and check what its startup sequence requires before it will report itself healthy.
- For each of those dependencies, ask whether an outage severe enough to cause the restart could also take out the dependency the restart needs.
- If a service can't start without a specific downstream connection, consider whether it can start in a degraded mode instead of blocking entirely, even if that mode is slower or more limited.
- Treat "the service restarted" and "the service recovered" as two different claims in your own monitoring, since Inngest's incident shows they can diverge for the full duration of an outage.
The honest limitation in Inngest's own report is that it doesn't name what caused the underlying database connectivity disruption in the first place, only how the response to it amplified the impact. Without that detail, it's not possible to say whether the root trigger was on Inngest's side, a cloud provider's side, or a network path between them, and Inngest's public writeup doesn't commit to one.
This is also the third incident report Inngest has published in October 2026 alone, and the company's own pattern across all three has been the same: a dependency that's supposed to provide resilience instead becomes the single path that an outage has to cross to end.
This is the same shape of problem we flagged in Inngest's earlier October connection pool collapse: a fix or a recovery mechanism that looks reasonable in isolation turns into the thing that extends the outage, once it shares a dependency with whatever already broke.
The verdict: an automatic restart is only as resilient as the thing it depends on to finish restarting, and if that dependency is the same system an outage has already taken down, the restart isn't recovery, it's a second failure wearing the first one's clothes.
The rule: before you trust an automatic restart to self-heal a service, check what that restart's startup sequence actually requires to succeed, and confirm that requirement can survive the exact class of outage the restart is meant to recover from.
FAQ
What caused the Inngest outage on October 20, 2026?
A connectivity disruption between Inngest's application infrastructure and its database caused two separate impact windows, 13:00 to 13:15 UTC and 15:20 to 15:35 UTC. Inngest's public report does not specify the root cause of the underlying connectivity loss itself.
Why did restarting Inngest's services make the outage worse?
Event ingestion services exhausted memory during the disruption and restarted automatically, but their startup process required a successful database connection to complete. Since database connectivity was still impaired, the restarted services couldn't finish coming back online until the underlying connectivity issue resolved.
How long did the Inngest outage last?
The incident had two separate windows of impact on October 20, 2026: a 15-minute window from 13:00 to 13:15 UTC, and a second 15-minute window from 15:20 to 15:35 UTC.
Is this the same incident as Inngest's earlier October outage?
No. This is a separate incident from the cross-data-center and connection-pooler failures Inngest reported for October 9 and 10, 2026. Both incidents share a general theme of a recovery mechanism amplifying rather than containing the original disruption, but the specific technical causes are different.
I'm Rohit, founder of Krova Cloud: disposable, per-minute-billed VMs that don't need to survive their own outage to come back online, because there's nothing worth recovering on a VM that's designed to be thrown away. More debugging stories at debugly.dev.
Top comments (0)