Why Discord bot uptime actually matters (and why nobody measures it honestly)
Go look at the front page of any Discord bot hosting service. You'll see the same three words, in different fonts, on different hero images: 24/7 uptime. BisectHosting has it. PebbleHost has it. The free tier at bot-hosting.net has it. Even the mysterious single-page storefronts on .xyz domains have it.
Now go look for the actual measured uptime percentage. You'll find it almost nowhere.
This is weird. Uptime is the thing we're supposedly selling. It's a number — you can compute it, you can publish it, you can show a chart. AWS publishes it per-region. Cloudflare publishes it per-service. The big database providers publish it to four decimal places with monthly breakdowns. Meanwhile, the Discord bot hosting industry, where uptime is arguably more important than most SaaS categories, publishes nothing.
Why uptime is different for Discord bots
Most web services recover gracefully from a minute of downtime. A user hits refresh; the retry works; nobody notices. Discord bots are different. They maintain a persistent WebSocket connection to the Discord gateway, and that connection carries a stateful protocol with identity, sequence numbers, and session resumes. When your bot goes down, it doesn't just stop serving requests — Discord knows it's gone, and depending on how long you're out, reconnecting is either a cheap resume or an expensive full re-identification that counts against your daily identify quota.
Practically, that means:
- A restart under 90 seconds can usually resume the gateway session. Users don't notice.
- A restart over 90 seconds invalidates the session. Your bot has to re-identify, which counts against the 1,000-per-day identify limit (lower for unverified bots). Users notice because the bot goes "offline" in the member list and slash commands briefly fail.
- A sustained outage eats through your identify quota. On shared hosts experiencing cascade failures, bots can end up unable to reconnect until the next 24-hour window.
This is why the "we restart every 6 hours" approach that some cheap hosting providers use is actively hostile. It artificially shreds sessions, eats identify quota, and makes your bot flap in ways that look, from your users' perspective, like you're running an unstable bot.
What a 99.9% SLA actually means
Uptime percentages sound abstract until you translate them into concrete downtime:
- 99.0% → 7.2 hours of downtime per month
- 99.5% → 3.6 hours / month
- 99.9% → 43 minutes / month ("three nines")
- 99.99% → 4.3 minutes / month ("four nines")
- 99.999% → 26 seconds / month ("five nines")
A 99.9% SLA, which Tumobird offers on all plans including the $1.99 Hobby tier, means that in a given month your Discord bot should experience no more than ~43 minutes of downtime caused by our infrastructure. Downtime inside your bot — a crash bug in your code, a bad deploy, an unhandled exception — isn't covered by the SLA, but auto-restart kicks in within 5 seconds of the process exiting, which materially compresses "my bot crashed" outages too.
Why so few providers publish real numbers
I think there are three reasons Discord bot hosting companies don't show measured uptime:
1. Shared nodes are unreliable by construction. If you oversubscribe CPU on a shared-tier host (and most cheap providers do; that's how the economics work), one rogue bot spiking into a hot loop can starve every other bot on the box. That's not even infrastructure downtime in the strict sense — it's resource contention — but the bot customer experiences it as outage. Publishing honest numbers would expose this.
2. Status pages lie by omission. Most bot host status pages show a dashboard of coloured rectangles. Green everywhere, always. But check the historical chart and you'll find gaps — "no data reported" windows — that coincide with the periods users complain about outages in Discord support channels. Modern observability is cheap enough that nobody has a technical reason to lose monitoring data. They have business reasons.
3. Nobody else is doing it, and it's a race to the bottom. Once the industry norm is to claim "24/7" without numbers, anyone who publishes real numbers looks worse by comparison — even if their uptime is genuinely better. Customers aren't calibrated. "99.87%" reads as imperfect; "24/7" reads as flawless. The market rewards vague claims.
How Tumobird measures uptime
We measure two things per deployment, every 30 seconds, from three independent probe locations:
Process health: is the container running, is memory usage within the tier limit, is the CPU not wedged.
Discord gateway liveness: is the bot emitting HEARTBEAT_ACK frames back to Discord on its expected interval. This is a Discord-specific check. The
process can be "up" in the Linux sense while the gateway connection is dead, and for a
Discord bot, gateway death is downtime. Generic host-level health checks miss
this.
Both metrics are aggregated and published to status.tumobird.com with 30-day
and 90-day rolling averages, per-region and in aggregate. When they slip below the 99.9%
SLA line for a billing month, service credits are issued automatically. You don't have to
file a ticket.
What to ask before choosing Discord bot hosting
If you're comparing hosts:
- Ask for the last 90 days of measured uptime, in writing, with a link to a public status page that shows the chart.
- Ask whether the health check is generic (Linux process alive) or Discord-aware (gateway heartbeats).
- Ask the auto-restart SLA: how many seconds between process exit and new-container-healthy.
- Ask whether the provider publishes incident postmortems and look at the last three.
- Ask whether shared tiers have CPU isolation (cgroup limits) or are best-effort.
If the answer to any of those is "we don't publish that" — that's your answer. Uptime is measurable. If your Discord bot hosting provider won't tell you what they measured, they probably measured something they'd rather you not see.
The economics of honest uptime
The reason Tumobird can offer a 99.9% SLA on the $1.99 Hobby tier is that we designed the platform around the assumption that uptime matters at every price point. Shared nodes use strict cgroup CPU limits, so one bot can't starve another. Memory is hard-capped, not best-effort. The supervisor is Discord-aware, which means we catch gateway-specific failure modes that generic platform supervisors miss. We pay for the infrastructure that lets us publish real numbers; customers pay the price that supports that infrastructure.
$1.99 is low. It is not "free plus hope." If you're running a Discord bot that matters to a community — even a small one — you deserve a host that treats uptime as a number to publish, not a slogan to print on the hero image.
The short version: "24/7" is not a measurement. 99.9% is. Pick a host that publishes the second.
Ready to host your bot on infrastructure with real numbers? Start your free 14-day trial →