the easiest part of a Telegram bot is often the part people call the bot.
receive /help, run a function, send a message. lovely.
keeping that bot alive on a server is a different project hiding behind the first one.
a process is not a service
running python bot.py proves the program can start. it does not make the program responsible for itself.
the SSH session closes. the process crashes. the server reboots. an API call hangs. without supervision, a perfectly good bot becomes a memory.
this is where systemd or another process supervisor earns its place. a service definition records the working directory, environment, startup command and restart behaviour.
ini[Service] WorkingDirectory=/opt/my-bot ExecStart=/opt/my-bot/.venv/bin/python bot.py Restart=on-failure RestartSec=5
automatic restart is useful, but it should not turn a permanent configuration error into an infinite high-speed crash loop. restart policy and logs belong together.
"active" can still be broken
systemctl may say the process is active while the bot has lost its connection, exhausted a rate limit or stopped consuming updates.
health needs layers:
- is the process running?
- is it still receiving events?
- can it reach Telegram?
- did the last important job succeed?
- is the queue growing while nothing leaves?
the right check depends on the bot. a simple command bot may need a heartbeat and an API check. a bridge should prove that messages are moving through both sides.
sessions are credentials with memory
user-account automation introduces session files. they look like ordinary files but contain authorization state and should be treated like secrets.
copying a session between machines carelessly can create conflicts. running the same authorization state from multiple locations may invalidate it or trigger errors. a backup is useful, but restoring a session does not guarantee that the remote service will still accept it.
sometimes the correct recovery is a fresh login on the one machine that will own the session.
the important phrase there is one machine.
logs should answer the next question
logs are not useful because they contain many lines. they are useful when they explain the failure.
for each important operation, i want enough context to answer:
- which bot or account was involved?
- what operation was attempted?
- was the failure temporary or permanent?
- will the system retry?
- what changed immediately before it stopped?
secrets and message contents do not need to be dumped everywhere. identifiers, error classes and state transitions are usually more useful than raw noise.
boring work is product work
users do not care that the command routing is elegant if the bot disappears every few days.
service supervision, session handling, backups, log rotation, health checks and recovery notes do not make exciting screenshots. they make trust. for software whose main promise is "i will be here when an event happens," staying alive is the feature.