Railway had a rough Wednesday. Builds were paused for about a day, and when they came back the status page asked people not to trigger the same deployment more than once. That's good advice for humans. An AI agent will never think of it on its own.
This post covers how an agent can tell "the platform is down" from "my deploy is broken," what it should do in each case, and the exact rules I paste into my agents' instructions file.
⭐ If this is useful, a star on GitHub helps other people find it.
🤖 Give this to your agent: point it at https://raw.githubusercontent.com/dennisonbertram/agentic-hosting/main/llms.txt and it can sign up and set things up from that one link.
What happened at Railway
I'm only repeating what Railway has published. On October 21, Railway disclosed that someone may have accessed encrypted environment variables (the settings where apps keep API keys and database passwords) and, for some of them, gotten the decrypted contents. Railway told every customer to rotate those secrets as a precaution, and paused all deployments while it investigated.
As of this morning, the status page says builds are back for Pro and Enterprise, the deploy queue is nearly cleared, and Railway is still working on Hobby, then Free and Trial.
I'm not writing this to pile on. Every platform has a bad day, including mine. But it's a clean example of a situation most agents have no plan for.
The question I got
On my last post, a reader named alexcodebytes asked something I've been chewing on since. If an agent has a backup place to deploy, how does it know when to use it? Can it tell "the platform is down" from "my deploy failed for some other reason"?
Left alone, mostly no. An agent sees an error and assumes it caused it. That's a reasonable guess most of the time, which is exactly why it's dangerous on the days it's wrong.
Check the platform before touching code
The fix is boring: make the agent look outside before it looks inside. Before it edits a single line to "fix" a failed deploy, it should answer three questions.
- Does the platform say it's down? Check the status page. If there's an open incident about builds or the API, stop there.
- Is it failing everywhere? If a deploy of the last version that worked also fails, the problem isn't the new code.
- Does the error point at my code? A build log with a compile error or a failing test is yours. A timeout, a 5xx error, or "service unavailable" usually isn't.
If all three point at the platform, it's an outage. If the error points at your code and the platform looks healthy, it's a broken deploy, and the agent should fix it like normal.
Then stop retrying
This is the part agents get worst. Each retry feels free to them. During an outage it just adds to the pile, which is why Railway asked people not to redeploy the same thing over and over.
My rule is two tries, then stop and tell me. No loops, no "let me try one more approach."
Rotate secrets where they're issued
If the incident involves leaked secrets, changing the value in the platform isn't enough. The old key still works until the company that issued it (your database host, your AI provider, your payment processor) revokes it. So the agent should list every key the app uses and I go revoke each one at its source.
I keep that step for myself. I don't want an agent revoking production keys on its own.
Fall back to a second place to ship
Only after all of that does the agent use the backup. For me that's agentic-hosting, an open-source program, ah, that turns a Linux server I own into a place agents can deploy apps and databases over an HTTP API.
Checking that the backup is up is one call, no key needed:
curl -s "$AH_URL/v1/system/health"
# {"status":"ok"}
Setting the new secrets and kicking off a build from git looks like this ($SVC is a service the agent already created there):
curl -s -X POST "$AH_URL/v1/services/$SVC/env" \
-H "Authorization: Bearer $AH_KEY" \
-H "Content-Type: application/json" \
-d '{"DATABASE_URL": "postgres://..."}'
BODY=$(jq -n --arg sha "$(git rev-parse HEAD)" '{
source_type: "git",
source_url: "https://github.com/you/app",
source_ref: $sha }')
curl -s -X POST "$AH_URL/v1/services/$SVC/builds" \
-H "Authorization: Bearer $AH_KEY" \
-H "Content-Type: application/json" \
-d "$BODY"
The build call answers with a build_id the agent can use to watch the build log.
The rules I paste in
Here's the block that lives in my agents' instructions file (CLAUDE.md, AGENTS.md, whatever yours uses):
When a deploy fails:
1. Read the build log. If it shows a compile
error or failing test, fix the code.
2. Otherwise check the platform status page
before changing any code.
3. If there is an open incident, or the last
good version also fails to deploy, it is
an outage. Do not edit code.
4. Retry at most twice. Then stop and tell me.
5. If the incident mentions leaked secrets,
list every key the app uses so I can
revoke each one where it was issued.
6. Only then, deploy to $AH_URL. Check
$AH_URL/v1/system/health first. Tell me
you switched and why.
It's not clever. It just writes down what a careful person already does.
What this costs
- You own the backup's uptime. If your box is down at 3 AM, there's no status page. There's you.
- Two places means two setups. Secrets, domains, and databases have to exist in both, and data doesn't move itself.
- The rules can still be wrong. A status page can lag, and an agent can still guess badly. This makes good calls more likely. It doesn't make them certain.
Wrapping up
When a platform goes down, the risk isn't just downtime. It's an agent retrying into a wall and "fixing" code that was fine. Teach it to check the platform first, stop after two tries, leave secret rotation to you, and only then ship somewhere else. agentic-hosting is one way to have that somewhere else on a server you own.
- Star agentic-hosting on GitHub so more people find it.
- Give it to your agent: llms.txt to sign up and set up, or the agent skill for daily use.
- Set up your own backup with the quickstart.
Top comments (0)