A look at why so many small bots go dark on free hosting platforms, why the cause is so often misdiagnosed, and how one small package is closing the gap.
The Quiet Problem Behind Thousands of "Randomly Offline" Discord Bots
Spend enough time in developer forums, Discord bot-hosting communities, or the comment sections of Telegram bot tutorials, and a pattern starts to emerge. It's not a bug report, exactly — nobody can point to a specific line of code. It's a recurring, half-frustrated question: why does my bot keep going offline for no reason? The answers vary in confidence and accuracy, ranging from "your hosting provider is bad" to "you probably have a memory leak" to, occasionally, the actual cause — one that has nothing to do with the bot's code at all.
A mismatch, not a malfunction
The root cause, once traced properly, is almost always the same: modern cloud hosting platforms were built primarily to serve web traffic, and they check whether a deployed service is "healthy" by trying to reach it over HTTP. A Discord bot, built with a library like discord.py, or a Telegram bot built on Pyrogram, doesn't work that way. It opens an outbound connection to Discord's or Telegram's own servers and simply waits there, listening for events. It never opens a port of its own — because it was never designed to need one.
To a hosting platform running an automated health check, that silence looks identical to a service that's broken. So it does what it's designed to do: it restarts the deployment, or marks it unhealthy, or eventually lets it spin down from inactivity. None of this is a platform malfunction. It's the platform behaving exactly as intended, against a workload it was never built to expect.
Why the misdiagnosis is so common
What makes this particular failure mode so persistent is how well it disguises itself. There's no exception in the bot's own logs, because nothing in the bot's own code actually failed. There's no obvious correlation with load, traffic, or a specific feature. From the developer's side, it looks exactly like an intermittent, unexplainable bug — which sends most people looking in exactly the wrong place, auditing their own command handlers for a fault that was never there.
It's a particularly costly kind of bug to misdiagnose, too, because the actual fix is small, and the wrong fixes people often land on instead — migrating to a more expensive VPS, rewriting large chunks of working code out of suspicion — cost real time and, frequently, real money, for a problem that never required either.
A narrow, well-defined fix
The actual solution has existed informally for years: run a minimal HTTP server alongside the bot, purely so the hosting platform has something to check. Developers have hand-rolled this fix repeatedly — a Flask app in a background thread, just complex enough to satisfy a health check and just fragile enough that it usually doesn't handle crash recovery, logging, or production-grade serving on its own.
That gap between "the minimal fix" and "a properly supervised deployment" is what a small, MIT-licensed Python package called StayPresent has set out to close. Rather than developers rebuilding the same Flask-in-a-thread workaround for every new bot, StayPresent packages it as a single function call:
import staypresent
staypresent.run("bot.py")
The call starts a lightweight HTTP server bound to whatever port the hosting platform expects, launches the bot as a supervised subprocess, and restarts it automatically if it genuinely does crash — distinguishing that from the platform simply never seeing an HTTP response in the first place.
A problem that scales with adoption, not complexity
What's notable about this particular category of tool is that it doesn't get more complicated as bots get more sophisticated — the underlying mismatch between "process with no HTTP port" and "platform expecting one" is exactly the same whether the bot handles ten commands or ten thousand. A newer release of the package adds a status dashboard and hang detection for bots that freeze without technically crashing, but the core fix for the original problem remains the same single line it always was.
The lesson underneath the bug
If there's a broader takeaway from how common this specific failure mode is, it's a reminder that not every intermittent bug is actually in the code you're staring at. Sometimes the fault line sits exactly at the boundary between two systems that were never designed with each other in mind — and the fix isn't a rewrite, it's a small adapter that finally lets the two speak the same language.
pip install staypresent[prod]
Top comments (0)