Uptime for agents: what 99.9% actually means and how to keep an agent online

Uptime for agents: what "three nines" actually means and how to keep an agent online

"99.9 percent" uptime appears on every hosting page, including ours. Most people can't translate that number into minutes, fewer know what it excludes, and almost nobody connects it to what actually breaks an AI agent. This article does all three: the arithmetic, the real failure modes, and the setup that keeps an agent alive when you're asleep.

The arithmetic first

Three nines allows about 8.7 hours of downtime per month — roughly 43 minutes per week. Four nines tightens that to 4.4 minutes per month. Two implications follow. First, three nines is a modest bar: your agent can be down every night for fifteen minutes and still qualify. Second, four nines is genuinely hard: it requires redundant everything, and it costs accordingly.

The number also has fine print everywhere. It usually measures platform availability, not your agent's availability. Your agent can be down while the platform shows green: a bad config you deployed, an expired API key, a workflow that crashed into an error loop, or a model provider outage upstream. When comparing providers, ask whether the percentage covers their control plane only or the runtime your processes run on — and remember that neither includes your own mistakes.

What actually takes agents down

Ranked by how often we see them in support:

1. Upstream API failures. The agent's model provider rate-limits, times out or has an incident. Your infrastructure is healthy; the brain is unreachable. This is the most common cause of "my agent stopped working" reports, and no amount of hosting redundancy fixes it — retry logic with backoff and a fallback model do.

2. Resource exhaustion. A memory leak in a long-running process, a disk filled by logs or accumulated files, a CPU spike from a runaway loop. Agents are unusual tenants: they run continuously, accumulate state (memories, caches, session files) and occasionally loop. Disk-full is the classic silent killer — the process runs fine until it doesn't write anymore.

3. Certificate and credential expiry. TLS certificates renew automatically on managed platforms but expire on self-hosted boxes; API keys and tokens expire on schedule and take the agent with them. Both failures are fully predictable and therefore inexcusable — put every expiry on a calendar.

4. Bad deployments. You update the agent's code or config, it crashes at startup, and the supervisor restarts into the same crash forever. The fix is deployment hygiene: keep the previous version runnable, change one thing at a time, and verify startup health before walking away.

5. Genuine platform incidents. Rare, real, and what the uptime percentage is actually about. This is the category redundancy and monitoring address — and ironically the least likely cause of your specific outage.

The setup that keeps an agent online

Four layers, in order of importance:

Supervision. The agent must run under something that restarts it on crash — systemd, Docker's restart policy, a process manager. A crashed agent that stays down is a choice, and it's the wrong one. Cap restart storms (e.g., stop after five failures in a minute) so a startup crash loops visibly instead of silently churning.

Health checks with teeth. "The process exists" is not health. An agent health check should verify the agent can actually act: a cheap round-trip to its model endpoint, a check that its memory store responds, a heartbeat file updated on each successful task cycle. Monitor the heartbeat's age — an agent whose last successful action was six hours ago is down even if the process is green.

Alerting that reaches you. One reliable channel beats five dashboards. Minimum set: heartbeat silence (agent stuck or dead), restart storm (crash loop), disk above 80%, and certificate expiry within 14 days. Everything else can go to a daily digest nobody panics about.

State outside the process. Memories, session history and configuration belong in persistent storage that survives restarts. If a crash wipes the agent's memory, you don't have an uptime problem — you have an amnesia problem, which is worse and slower to notice.

What this means for choosing where to run

Self-hosting gets you full control and full responsibility: layers one through four are yours to build, and the failure-mode list above becomes your personal checklist. Managed hosting bundles supervision, disk headroom, certificate renewal and often health-based restarts into the plan — you keep responsibility for your configs, keys and the upstream model account.

Whichever route you take, do the honest exercise once: write down what happens tonight if the model provider has a two-hour incident, if the disk fills, and if you deploy a broken config. If any answer is "the agent is gone until I notice," fix that first — it will be the cause of your next outage, not the platform's uptime number.