STATUS
TwitterAPIs status
This status page gives you a live check rather than a dashboard of stored history. When you load it, your browser asks this site to call the public health endpoint on the API host, and the result below is what that single request returned: the HTTP status, the round trip time, and whether the service reported capacity to serve. There is no historical uptime figure published here, and the section further down says exactly why.
Checking the API now
This is a single live request made when you loaded the page, repeated once a minute while the page is open. It reports what the API did just now. It is not a rolling average and it carries no history.
Why there is no uptime percentage on this page
An uptime figure is only meaningful when you can see three things: the window it covers, the probe that produced it, and what counted as a failure. A percentage printed without those is a decoration, and it is the kind of decoration that gets quoted back years after anybody checked it. We do not publish a measured history yet, so this page shows you a live probe you can repeat, and names the endpoint so you can run the same check yourself on your own schedule and keep your own series. When a published history exists it will appear here with its window and its method stated.
Run the same check yourself
The health endpoint is public. It takes no key, returns JSON, and is not a billed call, so it is safe to poll from an uptime service or a scheduled job. Treat a non-200, a timeout, or an unparseable body as a failure.
curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" \
https://api.twitterapis.com/healthA 200 means the service answered. If you are debugging a call that fails while this check passes, the problem is on the request rather than the service, and the REST API reference covers what each status code means. A 401 is a key problem, and the API key guide covers where a valid key comes from.
What to check when something looks wrong
Every call returns 401
The key is rejected. Confirm the header is Authorization with a Bearer prefix, or x-api-key with the bare value, and that the key has not been rotated out from under a deployed job holding an old copy.
A lookup returns an empty result
That is usually not an outage. A suspended, deleted or renamed account has no object to return, so the endpoint answers successfully with nothing in it rather than raising an error.
Calls stop mid-job
Check the remaining balance on the account endpoints. Billing is per call with no plan minimum, so a long pagination loop can exhaust a small balance without any warning from the loop itself.
Responses changed shape
Read the changelog. Endpoint additions and behaviour changes are recorded there with dates, which is the fastest way to tell a change from a fault.
If none of those explain it, the changelog records what shipped and when, and the contact page reaches a person rather than a queue.
Frequently Asked Questions
The check at the top of this page answers that for the moment you loaded it. It makes one unauthenticated request to the public health endpoint and reports the HTTP status and the round trip time it measured. A green result means the API answered that request. If you want an answer that does not depend on this page rendering correctly, request the health endpoint yourself, since it needs no key.
Point your monitor at the health endpoint on the API host. It answers without an API key, returns JSON, and does not bill you, so it is safe to poll on a schedule from an uptime service or a scheduled job. Treat a non-200, a timeout, or a body that fails to parse as the failure condition. That is the same signal our own monitoring reads.
The health endpoint is unauthenticated, so a green check confirms the service is reachable and serving, not that your particular request is valid. The three common causes are a rejected key, which returns 401, a request for an account that no longer exists, which returns an empty result rather than an error, and an exhausted balance. The account endpoints report your remaining credit, and support can confirm a key from our side.
No historical uptime figure is published today, and the check on this page is a live probe rather than a rolling average. We would rather say that plainly than print a percentage that has no measurement series behind it, because an uptime number is only worth anything when you can see the window it covers and the probe that produced it. A published history is a change we intend to make rather than one already shipped.
It is a derived verdict rather than a raw number: available means the API reported it had capacity to serve requests when the check ran, and constrained means it reported none. The underlying document carries more operational detail than is useful on a public page, so this page reduces it to the part that predicts whether your next call will succeed.
The changelog records what shipped and when, including endpoint additions and behaviour changes, which is where a change that broke your integration will be described. For anything that looks like an incident rather than a change, contact the team directly, because a person answers rather than a ticket queue.