How modelstatus.dev works
Availability, latency and throughput history for the endpoints that serve LLM models through OpenRouter — sampled every 5 minutes, published as it is collected.
What this is
When you call a model through OpenRouter, your request is routed to one of many provider endpoints — and each endpoint has its own uptime, latency and throughput. OpenRouter shows how each endpoint is performing right now, in a few rolling windows. It publishes no history: there is no way to ask what an endpoint looked like an hour ago, let alone last week.
This site closes that gap. Every five minutes a collector samples OpenRouter's per-endpoint metrics — roughly 400 models and 1,200 endpoints per round — and appends the readings to a permanent series. Everything here is derived from those samples: the incident lists, per-provider counts, the 90-day availability grids, and the charts.
How the data is collected
A cron trigger fires every five minutes, the model catalogue is split across a queue, and each shard fetches OpenRouter's endpoint metrics concurrently and writes one row per endpoint. Raw 5-minute rows are kept for 7 days; hourly rollups are kept permanently, and the 30-day views are built from those.
Collection runs as a separate service from the website on purpose: a missed round is a data point lost for good, because there is no historical API to backfill from. The pipeline reports on itself at /health — if sampling ever stops, that page is where it shows.
How to read the numbers
- Null is not zero. An endpoint with no traffic in the last 30 minutes reports no latency or throughput at all. The site shows a gap, never a 0 — a missing reading is not an outage.
- 5-minute uptime is exact. Consecutive 5-minute windows do not overlap at a 5-minute sampling interval, so the hourly uptime figures here are true hourly uptime.
- Latency and throughput are rolling windows. The p50/ p90/p99 figures are OpenRouter's pre-aggregated 30-minute windows. An hourly "p99" on this site is the mean of the hour's twelve window-p99 readings — quantiles cannot be averaged, and the column names say so.
- All timestamps are UTC. The server cannot know your time zone, and screenshots that disagree about the date are how outages get argued about.
What is deliberately not here
No site-wide uptime percentage and no provider leaderboard. Averaging 1,200 endpoints into one number hides both the dead tail and the healthy majority; ranking providers on weeks of history would be noise. The unit of truth on this site is the individual endpoint, so the pages show distributions and per-endpoint series instead.
Using the data
Everything is free and keyless. The API page documents the status JSON endpoint, the site-wide and per-model RSS feeds, and the embeddable status badges. For AI agents, /llms.txt is a machine-readable index of the site, and /llms-full.txt answers "what is down right now" in one plain-text fetch. The source code is public, including the schema and the collection pipeline.
FAQ
Is OpenRouter down right now?
Check the front page: endpoints that are down or degraded are listed at the top, split into in-progress, recently resolved and long-standing incidents. For a plain-text answer you can fetch without a browser, use /llms-full.txt, which carries the same snapshot.
How often is the data collected?
Every five minutes. Each round samples the uptime, latency and throughput figures that OpenRouter currently reports for every provider endpoint of every tracked model — roughly 400 models and 1,200 endpoints per round, with all timestamps in UTC.
Doesn't OpenRouter already publish this?
Only the current windows. OpenRouter exposes uptime for the last 5 minutes, 30 minutes and 24 hours, and latency and throughput for the last 30 minutes — but keeps no history. modelstatus.dev samples those windows every five minutes and keeps the series, which is what makes questions like "what did this provider look like last Tuesday" answerable at all.
What does "no data" mean?
That an endpoint carried no traffic in the recent window, so OpenRouter reports nothing for it. A missing reading is stored as an absence, never as zero — null is not an outage, and writing 0 would draw a false "latency collapsed to zero" cliff in the charts.
How are incidents detected?
Relative to each endpoint's own recent behaviour, not a global threshold: a reading below three standard deviations of that endpoint's 7-day hourly baseline (with an absolute floor for endpoints too new to have one) counts as degraded, and hard failures count as down. An incident opens after two consecutive bad rounds and closes after three good ones.
Why is there no single uptime percentage for the whole site?
That is a deliberate refusal, not a gap. Averaging about 1,200 endpoints hides both the permanently dead tail and the healthy majority behind one number, and with only weeks of history any provider ranking would be noise. The site shows distributions, per-provider counts and per-endpoint series instead.
Can I use this data in my own tools?
Yes. Every surface is free and needs no key: the status JSON endpoint, site-wide and per-model RSS feeds, embeddable SVG status badges, and the llms.txt index for AI agents. The API page documents all of them.