Is the Claude or OpenAI API down? How to check the provider status from the terminal
Back to the blog
Articletroubleshootingagente de programaçãodev toolsverboo codetutorial

Is the Claude or OpenAI API down? How to check the provider status from the terminal

MafraOctober 29, 20264 min read

Your coding agent started returning errors, timeouts or empty replies. Before you touch your config, reinstall the CLI or blame your own code, spend two minutes finding out whether the provider is down. This is the routine we use here, and it fits in one curl and a 20-line script.

Short answer: query https://status.claude.com/api/v2/status.json for the traffic light and https://status.claude.com/history.atom for the incident list. If there is an open incident on your model, the problem is not yours: switch models and keep going.

Three-step flow: check the traffic light with curl, read incidents with statuscheck.py and switch models with /model; branch for other providers
The whole flow: traffic light, incidents, model switch.

How do you quickly check if the provider is down?

Request the status page's status.json. The indicator field is none when everything is normal.

curl -s https://status.claude.com/api/v2/status.json

On 29 Oct 2026, the response was:

{"page":{"id":"tymt9n04zgry","name":"Claude","url":"https://status.claude.com","time_zone":"Etc/UTC","updated_at":"2026-10-29T12:28:38.680Z"},"status":{"indicator":"none","description":"All Systems Operational"}}

This endpoint is the traffic light. It tells you something is wrong, not what. For that you need the incident feed.

How do you list the incidents from the last 24 hours?

The status page publishes an Atom feed at /history.atom. Each incident is an entry with a title, an update date and the history of states (Investigating, Update, Monitoring, Resolved). The script below uses only the Python standard library and prints one line per incident.

import re
import sys
import urllib.request
import xml.etree.ElementTree as ET
from datetime import datetime, timedelta, timezone

URL = sys.argv[1] if len(sys.argv) > 1 else "https://status.claude.com/history.atom"
HORAS = int(sys.argv[2]) if len(sys.argv) > 2 else 24
NS = {"a": "http://www.w3.org/2005/Atom"}

req = urllib.request.Request(URL, headers={"User-Agent": "statuscheck/1.0"})
xml = urllib.request.urlopen(req, timeout=20).read()
root = ET.fromstring(xml)
corte = datetime.now(timezone.utc) - timedelta(hours=HORAS)
achou = False
for e in root.findall("a:entry", NS):
    upd = datetime.fromisoformat(e.find("a:updated", NS).text.replace("Z", "+00:00"))
    if upd < corte:
        continue
    achou = True
    titulo = e.find("a:title", NS).text
    html = e.find("a:content", NS).text or ""
    estados = re.findall(r"<strong>(\w+)</strong>", html)
    print(f"{upd:%d/%m %H:%M} UTC | {estados[0] if estados else '?'} | {titulo}")
if not achou:
    print(f"No incident updated in the last {HORAS}h.")

Save it as statuscheck.py and run it. The second argument is the window in hours:

python3 statuscheck.py https://status.claude.com/history.atom 72

Output on 29 Oct 2026, with a 72-hour window:

28/10 20:05 UTC | Resolved | Elevated errors affecting the Google Calendar connector
28/10 05:48 UTC | Resolved | Elevated errors affecting the Gmail connector
27/10 15:50 UTC | Resolved | Elevated errors for Claude Sonnet 5.5
27/10 09:56 UTC | Resolved | Elevated errors for Claude Sonnet 5.5

The second column is the incident's latest state. Resolved closes the matter. Anything else (Investigating, Monitoring) means the problem can still hit you.

Does it work for other providers?

Yes, just change the URL. We tested on the same date:

ProviderFeedState column
Claudehttps://status.claude.com/history.atomFilled
GitHubhttps://www.githubstatus.com/history.atomFilled
OpenAIhttps://status.openai.com/feed.atomShows ?

OpenAI's feed uses a different content format, so the script cannot extract the state and prints ?. The title and date are still correct. To get the state, open the entry link. One more detail: OpenAI's feed covers more than one product, and the title says which one was affected.

What should you do when the incident is on your model?

Stop debugging. A real case: on 27 Oct 2026, Claude's feed logged "Elevated errors for Claude Sonnet 5.5". Anyone on that model saw errors that no local change would fix. The practical move is to switch models and keep working.

In Verboo Code, that is the /model command inside the session. Because Verboo Code runs several models on the same plan, one model going down does not stall your day: you pick another and continue in the same conversation, with unlimited tokens.

How do you ask Verboo Code for this script?

Instead of copying the code, describe what you want and let Verboo Code write and test it. A prompt that works:

Create statuscheck.py using only the standard library. It reads a status page Atom feed
(URL as 1st argument, window in hours as 2nd, default 24) and prints one line per
incident updated in the window: UTC date, latest state and title.
Test it against https://status.claude.com/history.atom.

Also ask it to run the script against the real feed. That is what we did: testing with the day's data avoids a script that only works on the example.

What are the limits of this check?

  • The feed only records what the provider published. There is a gap between the problem starting and the incident appearing.
  • An "all normal" status does not prove the error is yours: partial, regional or account-level failures may not show up.
  • If the feed is clean and the error persists, then it is worth debugging your own config.

When a provider goes down, what matters is having another model at hand without switching tools. That is what Verboo Code delivers: create your account at verboo.ai and have several models ready for the next incident.

Enjoyed this article?
Share knowledge with your network.
// Read also

Related articles