From 3 Crashes a Week to Zero: A Small Change That Actually Worked

A before-and-after look at what changed when a Telegram bot's owner stopped manually restarting it every few days and let it recover on its own

From 3 Crashes a Week to Zero: A Small Change That Actually Worked

Some fixes are dramatic rewrites. This one wasn't. It was a single afternoon, one dependency, and a pattern that had been going on for months finally just... stopping. Here's what the before and after actually looked like.

Before: a routine nobody wanted

The bot in question was a Telegram bot handling media uploads for a community — nothing exotic, just a script that ran continuously, polling for new content and processing it. Two or three times a week, it would silently stop. Not crash loudly, not log an error — it would just go quiet, and stay quiet until someone manually SSH'd in and restarted it.

Over a few months, this turned into an actual routine: check the bot before bed, check it again first thing in the morning, keep a phone alarm set specifically to remind you to check on a piece of software. That's not sustainable, and it's not really "running a bot" anymore — it's babysitting one.

The investigation

The instinct, understandably, was to assume something in the upload-processing logic was leaking memory or hitting an unhandled edge case. Hours went into adding logging, wrapping handlers in try/except, checking memory usage graphs. Nothing conclusive turned up — the crashes didn't correlate with any particular kind of upload, time of day, or resource spike.

The actual cause turned out to be completely unrelated to any of that: the hosting platform expected an HTTP port, the bot never opened one, and the platform was periodically deciding the deployment was unhealthy and killing it — regardless of whether the bot's own logic was doing anything wrong at all.

After: one afternoon, one line

import staypresent

staypresent.run("bot.py")

That was, more or less, the entire fix. The bot's own code didn't change. What changed was that the hosting platform finally had something to check on, and if the process genuinely did crash for any reason, it came back up automatically instead of staying down until someone noticed.

The numbers

Three or more silent outages a week, averaging several hours of downtime each before anyone noticed and restarted it manually, became zero unplanned manual restarts in the following months. Not because the underlying bot logic got better — it didn't change at all — but because the actual cause of nearly every outage was never the bot's code in the first place.

What changed day to day

The phone alarm to check on the bot got deleted. The habit of glancing at logs first thing in the morning, dreading a wall of silence, quietly stopped. And with the newer status dashboard, checking on the bot went from "SSH in and hope for the best" to opening a link and seeing uptime, restarts, and incident history at a glance — the kind of visibility that used to require actually going looking for a problem to notice one.

If this sounds familiar

If you're maintaining a bot and you've built your own version of the "check it before bed, check it in the morning" routine, there's a real chance you're solving the wrong problem — spending your effort on the bot's logic when the actual gap is somewhere else entirely.

pip install staypresent[prod]

One afternoon. One line. Worth checking before you spend another few months on a routine you shouldn't need.