How to check if an API is down
Step 1: Check DNS resolution
Every API request begins with DNS — translating the domain name into an IP address. If this step fails, nothing else matters. The request can't even begin.
When you run a check with the tool above, the first thing it does is a DNS lookup. A successful lookup typically takes 5–50 milliseconds. If DNS resolution fails, you'll see an error immediately, and the tool will tell you the domain couldn't be resolved.
What DNS failure means: the domain name is wrong, your DNS server is down, or the API provider's DNS records are misconfigured. Try switching to a public DNS resolver like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare) to rule out local DNS issues.
What DNS success means: the domain exists and can be found. Move on to the next step. DNS time is included in the diagnostics so you can spot if it's abnormally slow (over 200ms), which can sometimes indicate DNS-level throttling or an overloaded resolver.
Step 2: Verify TLS/SSL
After DNS resolves the IP address, the next step is establishing a secure connection via TLS (Transport Layer Security). Almost all modern APIs use HTTPS, so the TLS handshake is a critical step.
During the TLS handshake, your client and the server agree on an encryption protocol, verify the server's certificate, and establish a secure channel. This typically takes 50–200 milliseconds. Our checker measures this time separately so you can see if TLS is the bottleneck.
What TLS failure means: the server's SSL certificate might be expired, revoked, or misconfigured. A corporate proxy might be intercepting and re-signing HTTPS traffic (common in enterprise networks). The server might not support the TLS version your client is using.
What TLS success means: the secure connection is established. The server's identity is verified, and encrypted communication is ready. If TLS succeeds but the HTTP request fails, the problem is at the application layer — not the network.
For more on how TLS failures differ from other errors, see our guide on API timeout vs DNS error.
Step 3: Test the HTTP response
Once DNS and TLS are working, the actual HTTP request is sent. This is where the API processes your request and returns a response. The HTTP status code tells you what happened.
- 200–299 — the API is up and working. The request succeeded. If you're getting 200 from this tool but errors in your app, the issue is likely in your request format, authentication, or network path.
- 301, 302, 308 — redirects. The API is up but sending you somewhere else. This usually isn't a problem but can cause issues if your client doesn't follow redirects.
- 400–499 — client errors. The server is up but rejecting your request. Common causes: bad authentication (401), missing permissions (403), wrong endpoint (404), or rate limiting (429).
- 500–599 — server errors. The API is having problems. 502 (Bad Gateway) and 503 (Service Unavailable) are the most common outage indicators. 504 (Gateway Timeout) means an upstream server didn't respond in time.
- No response — a timeout at this stage means the connection was made but the server never sent data back. This is the classic "the API is down" scenario.
Step 4: Measure latency and performance
Even when an API is technically "up," it can be so slow that it's effectively unusable. The final diagnostic step is checking response times, especially TTFB (Time To First Byte).
TTFB (Time To First Byte) measures how long it takes from sending the request to receiving the first byte of the response. This is the best indicator of server-side processing speed. A healthy API should have a TTFB under 500ms for simple requests. Over 3 seconds suggests the server is under heavy load.
Total time includes everything: DNS, TCP connection, TLS, server processing, and data transfer. Comparing total time against TTFB tells you whether the slowness is in the server processing (high TTFB) or in data transfer (high total time but low TTFB).
The checker above shows all of these metrics in a clear breakdown: DNS, TLS, TTFB, and total time. Use them to identify exactly where the bottleneck is.
If the API responds but with degraded performance, check whether the service has a status page reporting partial outages. Services like OpenAI, AWS, and Stripe all publish real-time status information.
Quick diagnosis checklist
- Step 1: Verify DNS — can the domain name be resolved to an IP address?
- Step 2: Check TLS — does the secure handshake complete successfully?
- Step 3: Test HTTP — does the server return a response, and what status code?
- Step 4: Measure latency — is the TTFB and total time within acceptable ranges?
- Step 5: Compare — test from multiple networks to isolate local vs global issues
- Step 6: Check the official status page for the service, if one exists
Frequently asked questions
How do I check if an API is down?
Test the API endpoint from an external server (not your local machine) using a tool like this one. Check four stages: DNS resolution, TLS handshake, HTTP response code, and response latency. If any stage fails, you've found the problem.
What is the difference between an API being down and being slow?
An API is 'down' when it doesn't respond at all — you get a timeout, connection refused, or DNS failure. An API is 'slow' when it responds but takes longer than expected. The diagnostics breakdown (DNS, TLS, TTFB, total time) helps you distinguish between the two.
What does DNS resolution mean in an API check?
DNS resolution is the process of converting a domain name (like api.example.com) into an IP address. It's the first step in any API request. If DNS fails, nothing else can proceed. A healthy DNS lookup takes 5-50ms.
What does TTFB mean?
TTFB stands for Time To First Byte. It measures how long it takes from sending the HTTP request to receiving the first byte of the response. A high TTFB (over 2-3 seconds) usually means the server is under load or processing slowly.
Why does my API check succeed from this tool but fail from my app?
This tool checks from our servers, which may be on a different network than your application. The issue could be in your local network, firewall rules, DNS resolver, proxy configuration, or geographic routing. Try testing from the same region as your app's servers.
How often should I check if my API dependencies are up?
For production applications, implement automated health checks that run every 30-60 seconds. Use these to trigger alerts before your users notice. For manual checks during incidents, recheck every 2-5 minutes until the issue resolves.
What HTTP status codes mean the API is down?
Status codes 502 (Bad Gateway), 503 (Service Unavailable), and 504 (Gateway Timeout) typically indicate server-side issues. A 500 (Internal Server Error) may be a bug rather than an outage. Codes in the 200 range mean the API is up. Codes 400-499 usually mean a client-side problem.