Is Claude down right now? Anthropic's status page, status.claude.com, answers that. What it doesn't show at a glance is the pattern: how often Claude has incidents, which part breaks, how long they last, and how that compares with the other services an AI agent depends on. So we asked Claude to build a tracker that reads the public status pages of Claude, OpenAI, GitHub, Cursor, Vercel and Supabase every hour, keeps every incident, and draws them on a dashboard with a public link. Open the live status tracker: it updates by itself.
The short answer: Anthropic posted 427 incidents on Claude's status page in the 12 months to 27 October 2026, about 36 a month. A third were rated major or critical, and half were resolved within an hour (the median was 59 minutes). Incidents peaked between February and July 2026 at 41 to 58 a month and fell to between 13 and 25 a month from August, though more of the recent ones were rated major. Most happen on weekdays. To see whether Claude is down this minute, check status.claude.com; to see the history, use the tracker.
Fastero
Point Claude at your database.
Add Fastero to claude.ai or Claude Code. Claude builds the dashboard, deploys the app or publishes a live page, and your team opens it in Fastero.
Try free →
The status tracker in Fastero. Live data from the services' status pages, 27 October 2026.
Claude incidents per month
Incidents Anthropic posted on status.claude.com, and how many it rated major or critical:
| Month | Incidents | Major or critical |
|---|---|---|
| November 2025 | 26 | 7 |
| December 2025 | 21 | 8 |
| January 2026 | 26 | 6 |
| February 2026 | 58 | 15 |
| March 2026 | 51 | 21 |
| April 2026 | 49 | 16 |
| May 2026 | 41 | 17 |
| June 2026 | 48 | 10 |
| July 2026 | 54 | 16 |
| August 2026 | 25 | 8 |
| September 2026 | 13 | 8 |
| October 2026 (to the 27th) | 15 | 11 |
An incident is a post on the status page, not a measure of downtime. One incident can be a single model returning errors for twenty minutes or every product being unreachable for hours, and Anthropic posts minor slowdowns as well as outages. Read the counts as a trend.
Which part of Claude breaks
Of the 57 incidents in the last 90 days, each naming one or more parts of Claude:
| Part | Incidents |
|---|---|
| claude.ai | 43 |
| Claude Cowork | 40 |
| Claude Code | 39 |
| Claude API (api.anthropic.com) | 38 |
| Claude Console (platform.claude.com) | 10 |
Most incidents, 43 of the 57, name several parts at once: a problem with a model reaches the apps, Claude Code and the API together. The Console is named least, but an incident naming it alone was the longest of the quarter.
How long incidents last
Over the last 90 days, half of Claude's incidents were resolved within 47 minutes. Over the year, the median was 59 minutes and one incident in ten lasted longer than four and a half hours. The longest of the last 90 days were partial problems left open for days: errors on platform.claude.com from 7 October, resolved after 149 hours, and degraded Claude Cowork on Windows from 10 September, after 99 hours. The longest broad incident was "Degraded performance of multiple models" on 5 August, at seven hours.
When incidents happen
Incidents follow the working week. Over the year, Tuesdays had 91, Wednesdays 85 and Mondays 70, while Saturdays had 37 and Sundays 21 (by the day they started, in UTC).
How Claude compares with other services
Incidents each service posted in the 14 days to 27 October 2026:
| Service | Incidents | Rated major or critical | Median minutes to resolve |
|---|---|---|---|
| OpenAI | 19 | 2 | 78 |
| Cursor | 16 | 2 | 43 |
| GitHub | 10 | 2 | 51 |
| Claude | 9 | 7 | 40 |
| Supabase | 9 | 3 | 82 |
| Vercel | 1 | 0 | 62 |

Incidents per service on the tracker, 27 October 2026.
Compare these with care. Each company decides what counts as an incident and how severe it is: Anthropic rated seven of its nine "major", OpenAI two of its nineteen. The other services' feeds return only their latest 25 to 50 incidents, which reach back to between May and early October 2026 depending on the service, and the tracker's history of them grows from there; only Claude's goes back a year.
How Claude built the tracker
The setup is the one from our GitHub stars and npm downloads tracker: a Postgres database the job can write to, its address saved in Fastero under Settings → Secrets, and the same database connected read-only for the charts. Status pages need no key.
With Fastero connected to Claude, the prompt:
In Fastero, build a status tracker for the services our agents depend on: Claude,
OpenAI, GitHub, Cursor, Vercel and Supabase. Every hour, a Python job should read each
one's public status feed (/api/v2/incidents.json) and save every incident with its
impact, start, resolution and the parts it affected into a table in the trackers schema
of the database in the Secret OSS_DATABASE_URL, updating an incident until it is
resolved. On its first run, fill in the last year of Claude's incidents from its status
page's history.
Then build a dashboard: Claude incidents this month, the median time to resolve, open
incidents now, Claude incidents per month, the parts affected, incidents per service
in the last 14 days, and the latest incidents. Refresh it when the data changes, and
ask for a public link.What Claude did, through Fastero's connector:
| Step | Fastero tool | What happened |
|---|---|---|
| 1 | fastero_create_python_project |
A Python project, "Service status tracker" |
| 2 | fastero_write_python_file |
main.py, below |
| 3 | fastero_run_python_project |
"Saved incidents: Claude 447, OpenAI 25, GitHub 50, Cursor 50, Vercel 50, Supabase 25." |
| 4 | fastero_set_python_schedule |
5 * * * *: every hour, at five past |
| 5 | fastero_save_chart, seven times |
Three number cards, a monthly chart, two bar charts and the latest incidents |
| 6 | fastero_set_dashboard_refresh |
Charts re-run when the table changes |
| 7 | fastero_share_dashboard |
A public link, published once a person confirmed it in Fastero |
The first run took about two minutes, most of it reading Claude's history one incident at a time; each hourly run after it takes a few seconds. Each status feed returns only its latest incidents, so the job updates the ones it already has and adds the new ones, and the history keeps growing.
The job, as it runs every hour:
"""Service status tracker.
Every hour: the incidents Claude, OpenAI, GitHub, Cursor, Vercel and Supabase publish on
their status pages, saved into Postgres (the Secret OSS_DATABASE_URL), one row per incident,
updated until it is resolved. Each feed returns only the latest 25 to 50 incidents, so
history builds up from the first run; Claude's status page also keeps its full history, so
the first run fills in Claude's last year from it.
"""
import datetime as dt
import json
import os
import time
import urllib.error
import urllib.request
import psycopg2
from psycopg2.extras import execute_values
SERVICES = {
"Claude": "https://status.claude.com",
"OpenAI": "https://status.openai.com",
"GitHub": "https://www.githubstatus.com",
"Cursor": "https://status.cursor.com",
"Vercel": "https://www.vercel-status.com",
"Supabase": "https://status.supabase.com",
}
BACKFILL_DAYS = {"Claude": 365}
TABLE = """
CREATE TABLE IF NOT EXISTS trackers.status_incidents (
service text NOT NULL,
incident_id text NOT NULL,
name text NOT NULL,
impact text,
status text,
started_at timestamptz NOT NULL,
resolved_at timestamptz,
components text[],
link text,
PRIMARY KEY (service, incident_id)
)"""
def get(url):
req = urllib.request.Request(
url, headers={"User-Agent": "fastero-status-tracker (+https://fastero.com)", "Accept": "application/json"}
)
for attempt in range(3):
try:
with urllib.request.urlopen(req, timeout=30) as response:
return json.load(response)
except urllib.error.HTTPError as e:
if e.code in (429, 500, 502, 503) and attempt < 2:
time.sleep(10 * (attempt + 1))
continue
raise RuntimeError(f"{url} answered {e.code}") from e
def row(service, base, i):
return (
service,
i["id"],
i["name"],
i.get("impact"),
i.get("status"),
i["created_at"],
i.get("resolved_at"),
sorted({c["name"] for c in i.get("components") or []}),
i.get("shortlink") or f"{base}/incidents/{i['id']}",
)
def history(service, base, days):
# The history page lists incidents month by month, newest first, three months a page;
# each incident's own page has its times and the parts it affected.
since = dt.date.today() - dt.timedelta(days=days)
rows = []
for page in range(1, 50):
months = get(f"{base}/history.json?page={page}").get("months") or []
for m in months:
month = dt.date(m["year"], dt.datetime.strptime(m["name"], "%B").month, 1)
if month < since.replace(day=1):
return rows
for i in m.get("incidents") or []:
rows.append(row(service, base, get(f"{base}/api/v2/incidents/{i['code']}.json")["incident"]))
if not months:
return rows
return rows
def main():
conn = psycopg2.connect(os.environ["OSS_DATABASE_URL"])
try:
with conn, conn.cursor() as cur:
cur.execute(TABLE)
cur.execute("SELECT DISTINCT service FROM trackers.status_incidents")
seen = {r[0] for r in cur.fetchall()}
counts = {}
for service, base in SERVICES.items():
rows = [row(service, base, i) for i in get(f"{base}/api/v2/incidents.json")["incidents"]]
if service in BACKFILL_DAYS and service not in seen:
rows += history(service, base, BACKFILL_DAYS[service])
rows = list({r[1]: r for r in rows}.values()) # an incident in both lists once
execute_values(
cur,
"INSERT INTO trackers.status_incidents VALUES %s ON CONFLICT (service, incident_id) DO UPDATE SET "
"name = EXCLUDED.name, impact = EXCLUDED.impact, status = EXCLUDED.status, "
"started_at = EXCLUDED.started_at, resolved_at = EXCLUDED.resolved_at, "
"components = EXCLUDED.components, link = EXCLUDED.link",
rows,
)
counts[service] = len(rows)
finally:
conn.close()
print("Saved incidents: " + ", ".join(f"{s} {n}" for s, n in counts.items()) + ".")
if __name__ == "__main__":
main()To track another service, add its status page to SERVICES. Status pages hosted on Atlassian Statuspage answer at the same /api/v2/incidents.json address, and so do some others, such as OpenAI's and Supabase's.
Get an email when Claude has an incident
Ask Claude: "Email me when Claude or OpenAI has an open incident." It saves a query that counts the open incidents of those two services, and a Fastero alert runs it on a timetable, at most once an hour, and emails when the count rises above zero and again when it falls back to zero. It doesn't email again while the incident stays open.
The table answers other questions too, in a chat with Claude: "How many Claude Code incidents were there last month, and how long did they last?", "Which hours of the day have the most Claude API incidents?", or "Draw incidents per week for each service since the tracker started."
FAQ
Is Claude down right now?
Anthropic's status page, status.claude.com, shows the live state of claude.ai, the API, Claude Code, Claude Cowork and the Console, with any open incident. The tracker reads it every hour, so its "open incidents" card can be up to an hour behind.
How often does Claude go down?
Anthropic posted 427 incidents on Claude's status page in the 12 months to 27 October 2026, about 36 a month, a third of them rated major or critical. The monthly count ranged from 13 in September 2026 to 58 in February 2026.
How long do Claude outages last?
Usually under an hour. Half of Claude's incidents in the last 90 days were resolved within 47 minutes, and half over the year within 59. One in ten lasted longer than four and a half hours, and two thirds of those long ones were rated minor.
Does Claude Code go down when claude.ai does?
Often, but not always. Over the last 90 days, claude.ai was named in 43 incidents and Claude Code in 39, and most incidents named several parts of Claude at once. Each incident on status.claude.com lists the parts it affects.
How can I monitor the AI services my agent depends on?
Read their status pages on a schedule and keep what you read: most offer the same JSON feed, so one short job covers them all, and a table of incidents lets you count, compare and alert. The job and the dashboard above do exactly that, built by Claude through Fastero's connector.
Fastero Dev Team