Is Inngest Down?

No — Inngest is up

Reachable from all 8 checked regions

Average response time: 192ms

Last checked 1 hour ago · checks run every 6 hours

Official status page: https://status.inngest.com

Inngest uptime

100%

Last 7 days

100%

Last 30 days

100%

Last 90 days

183ms

Avg response, 30 days

Measured from multiple regions every 6 hours. Percentages count only checks that returned an availability answer — 19 days measured so far. A dash means that window does not yet hold enough measured days to publish a figure.

30-day history

19-day clean streak

Aug 22 Today

No downtime Partial Downtime Not measurable No data

Reachability by region

Each region runs its own request from a different part of the world. A service can be up for one continent and down for another, which is usually the first sign of a routing or CDN problem.

ams

169ms

DNS 34ms TCP 8ms TLS 27ms TTFB 144ms

arn

266ms

DNS 191ms TCP 6ms TLS 13ms TTFB 259ms

nrt

251ms

DNS 179ms TCP 3ms TLS 8ms TTFB 240ms

ord

135ms

DNS 46ms TCP 1ms TLS 24ms TTFB 122ms

sin

207ms

DNS 145ms TCP 1ms TLS 11ms TTFB 196ms

sjc

101ms

DNS 28ms TCP 1ms TLS 12ms TTFB 92ms

syd

207ms

DNS 145ms TCP 1ms TLS 8ms TTFB 200ms

yyz

203ms

DNS 47ms TCP 12ms TLS 40ms TTFB 164ms

What Inngest does

Inngest is a durable execution platform for background jobs and workflows. Applications send it events over an HTTP API, and Inngest runs the functions subscribed to those events with retries, concurrency limits, delays and multi-step flows. Teams use it instead of running their own queue and worker infrastructure, so scheduled work and asynchronous processing depend on it.

What an outage looks like

Background work stops happening while the application itself looks healthy. Inngest reports Event API separately from Function execution, so events can be accepted normally while the functions subscribed to them never run, leaving a backlog with no error anywhere in your code. Scheduled and delayed steps are the first thing users notice missing.

What to do about it

Read status.inngest.com, which publishes uptime per component next to the current state. If Function execution is the affected row, treat queued work as not yet run rather than lost, and avoid re-sending events, since duplicates will execute once the backlog clears. If only the Inngest Dashboard is affected, functions are still running and you have lost visibility rather than execution.

Is it down for everyone, or just you?

If this page says Inngest is up but it is not loading for you, the problem is between you and them. Run a check against any URL from up to 18 cities across three regions to find out where it breaks.

Test it yourself

Related services

Vercel

AWS

Upstash

Sentry

Inngest outage FAQ

My events are being accepted but nothing runs. Is Inngest down?

That is the shape of a Function execution incident. Inngest reports the Event API separately, so it can keep returning success for events your application sends while the functions subscribed to them do not execute. Your code sees no error because the send succeeded. Check the Function execution row on status.inngest.com before debugging your own handlers.

Will events sent during an Inngest outage be lost?

Events accepted by the Event API are recorded, so an execution incident usually means delayed rather than dropped work. Inngest does not publish a guarantee covering every failure mode, so confirm against the incident's own updates rather than assuming. Avoid re-sending events during the window, because both copies will run once execution recovers.

The Inngest dashboard will not load. Are my functions still running?

Probably, and the two are reported separately. Inngest lists the Inngest Dashboard and Observability as components apart from Function execution, so you can lose the ability to inspect runs while the runs themselves continue normally. Treat it as lost visibility, and avoid triggering replays whose results you cannot see.

How do I tell an Inngest outage from a bug in my own function?

Compare the scope. A fault in your function affects that function and shows up in its run history with errors, while an Inngest incident stops or delays runs across every function at once, often with no run recorded at all. status.inngest.com publishes per-component uptime, so a dip on Function execution confirms the platform side.

How we measure this

We request Inngest's public endpoint every 6 hours from Fly.io regions across six continents — the most recent check ran from 8 of them.
A region counts as down only when it gets no usable HTTP response. A 403 or 429 means the origin answered and refused us, which we report as blocked, never as an outage.
A single failing region is treated as probe noise. We only change the verdict when two consecutive cycles agree.
Response times average only the regions that actually served the page, so a timeout never inflates the number.
Where Inngest publishes an official status feed we read it too. An all-clear from the vendor can soften an unconfirmed degradation; a vendor-declared outage only worsens our verdict when our own checks corroborate it.

Get alerted when Inngest goes down

This page refreshes every 6 hours. Your own monitors run as often as every 30 seconds, from up to 18 cities across three regions, and tell you the moment something breaks.

Start Free Monitoring

Free plan available No credit card required