The API I Use Is Down. What Do I Do Now?
Your script was running fine. You built it with Claude, ChatGPT, or Gemini, and it was doing exactly what it was supposed to do. Then it stopped. You check the…
Your script was running fine. You built it with Claude, ChatGPT, or Gemini, and it was doing exactly what it was supposed to do. Then it stopped. You check the error logs and see something like “connection refused,” “service unavailable,” or “503 error.” You did not change anything. Your code is correct. But your script is failing and you have no idea if it is your fault or someone else’s. The answer is almost certainly that the API you are using is having problems, not you. Here is exactly what to do when an API you depend on goes down.
How to Confirm the API Is Actually Down
Before spending time debugging your own code, confirm the problem is external.
Check the service’s status page. Almost every major API has a public status page where they report incidents. Common ones:
- OpenAI: status.openai.com
- Stripe: status.stripe.com
- GitHub: githubstatus.com
- Vercel: vercel-status.com
- Twilio: status.twilio.com
If there is an active incident listed, the API is down and there is nothing you can do except wait. This takes thirty seconds to check and saves you hours of debugging code that is not the problem.
Check Downdetector. For services without a dedicated status page, downdetector.com aggregates user reports of outages. Search for the service name and you will see recent reports.
Try the API directly. Paste an API endpoint URL into your browser or use a free tool like reqbin.com to make a simple test request. If it fails with a 503 error, the service is down.
Understanding the Error Codes
When an API is having problems, it typically returns specific HTTP status codes:
503 Service Unavailable: the server is temporarily unable to handle requests. Usually means the service is overloaded or down for maintenance.
502 Bad Gateway: a server received an invalid response from another server it was communicating with. Often appears during outages.
504 Gateway Timeout: the server did not receive a response in time. Usually a sign of overload or infrastructure problems.
429 Too Many Requests: this one is different. It means you are hitting rate limits, not that the service is down. We covered this in the rate limiting post.
What to Do While the API Is Down
Stop your script from running repeatedly. If your script runs on a schedule and keeps trying to call a down API, it will generate a cascade of errors and may exhaust any rate limits or quotas when the service comes back. Pause the schedule temporarily.
Check how critical the outage is. Is this a minor automation that can wait, or something affecting users of your app right now? That determines how urgently you need to act.
Add error handling for next time. When the service comes back, ask your AI: “Can you add error handling to my script so that if the API returns a 503 or 502 error, it retries after a few minutes instead of failing immediately?” This is called retry logic and it makes your script resilient to temporary outages.
Set up an uptime alert. Services like Better Uptime at betteruptime.com monitor third-party APIs and alert you when they go down, before your script starts failing. Free tier available.
How to Build a More Resilient Script
The professional approach to external API dependency is building your script to handle outages gracefully:
Retry logic: automatically retry failed requests after a delay, with increasing wait times between retries.
Fallback behaviour: if the API is down, do something else instead of failing completely. Log the failure, queue the task for later, or notify you.
Circuit breaker pattern: after a certain number of consecutive failures, stop trying the API entirely for a period to avoid hammering a struggling service.
Ask your AI: “Can you add retry logic and graceful error handling to my script so it handles temporary API outages without crashing?”
The One Thing to Remember
When your script fails with a 503, 502, or 504 error, check the API’s status page before debugging your own code. If the service is down, wait and pause your script. When it comes back, add retry logic so future outages do not cause crashes. External API downtime is a normal part of building on third-party services, not a sign that your app is broken.
Want your scripts running reliably even when third-party services have problems? → Snapdock
New here? These might help: What does “rate limiting” mean? Why your script suddenly stops working. → What are logs? How to read them when your app breaks. →