DEV Community: John Wick

How to Run a Python Bot on Fly.io Without It Sleeping

John Wick — Sat, 22 Aug 2026 13:13:41 +0000

A tutorial for deploying a python bot on Fly.io with proper health checks and no unwanted machine suspension, using StayPresent.

How to Run a Python Bot on Fly.io Without It Sleeping

Fly.io deploys apps as lightweight VMs ("Machines") close to your users, and its free allowance is a popular choice for small bots. It also has a specific behavior worth understanding before you deploy: Fly can automatically stop machines when they're idle, and restart them on the next incoming request — great for a web app, potentially disruptive for a bot that needs to stay connected continuously. This tutorial covers deploying a Python bot on Fly.io correctly, avoiding both the standard HTTP-port issue and Fly's specific auto-stop behavior.

How Fly.io's Health Checks Work
Fly's Auto-Stop/Auto-Start Behavior
Step 1: Install StayPresent
Step 2: Wrap Your Bot's Entry Point
Step 3: Configure fly.toml
Step 4: Disable Auto-Stop for a Bot Machine
Step 5: Deploy
Verifying It's Actually Staying Up
FAQs
Conclusion

How Fly.io's Health Checks Work

Like most modern platforms, Fly can be configured to check your service over HTTP and restart it if it stops responding. A Discord or Telegram bot doesn't open an HTTP port on its own, so without something bridging that gap, a configured health check has nothing to actually verify.

Fly's Auto-Stop/Auto-Start Behavior

This is the part that's specific to Fly and worth calling out: Fly Machines can be configured to automatically stop when idle and start again on the next request — a cost-saving feature that makes sense for a typical web app, but works against a bot that's supposed to maintain a continuous connection to Discord or Telegram in the background, with no incoming HTTP requests driving that connection at all.

Step 1: Install StayPresent

pip install staypresent[prod]

# requirements.txt
staypresent[prod]

Step 2: Wrap Your Bot's Entry Point

Your bot logic in bot.py stays unchanged:

# main.py
import os
import staypresent

staypresent.web.json({"status": "running"})

staypresent.run(
    "bot.py",
    port=int(os.getenv("PORT", 8080)),
)

Step 3: Configure `fly.toml`

app = "my-bot"

[env]
  PORT = "8080"

[[services]]
  internal_port = 8080
  protocol = "tcp"

  [[services.ports]]
    port = 80
    handlers = ["http"]

  [[services.tcp_checks]]
    interval = "15s"
    timeout = "2s"

This gives Fly the HTTP surface it's looking for to consider your machine healthy.

Step 4: Disable Auto-Stop for a Bot Machine

This is the step specific to Fly that's easy to miss. In fly.toml, make sure auto-stop isn't configured against your bot service — a bot needs to stay running continuously, not spin down between requests the way a typical stateless web app would:

[[services]]
  internal_port = 8080
  protocol = "tcp"
  auto_stop_machines = false
  auto_start_machines = false
  min_machines_running = 1

min_machines_running = 1 specifically ensures Fly always keeps at least one instance of your bot running, rather than scaling it down to zero during a quiet period.

Step 5: Deploy

fly deploy

Verifying It's Actually Staying Up

Check fly status to confirm your machine is showing as started consistently, not cycling between stopped and started. You can also hit /health directly via your app's Fly URL to confirm StayPresent's HTTP server is responding. On a recent StayPresent version, /status gives you an ongoing uptime view, which is the clearest way to confirm the bot is staying connected over time rather than restarting repeatedly.

FAQs

Do I need staypresent.cron() on Fly.io too?
Generally no, if auto_stop_machines = false and min_machines_running = 1 are set correctly — those settings are what actually control Fly's idle behavior, unlike platforms where self-pinging is the main lever.

Does this work the same for a Telegram bot as a Discord bot?
Yes — the fix addresses the HTTP port and auto-stop behavior generically, regardless of which bot library or platform API your bot talks to.

Will min_machines_running = 1 cost more than the free tier allows?
Fly's specific pricing and free allowances change over time — check Fly's current pricing page for your usage before assuming either way.

Conclusion

Running a Python bot reliably on Fly.io means solving two separate things: giving Fly's health check an HTTP port to verify (via staypresent.run()), and explicitly disabling Fly's auto-stop behavior so your bot isn't treated like a scale-to-zero web app. Both together keep your bot connected and online continuously, the way a bot actually needs to run.

pip install staypresent[prod]

Fixing "Address Already in Use" When Redeploying a Python Bot

John Wick — Sat, 22 Aug 2026 13:13:17 +0000

A tutorial for diagnosing and fixing OSError: Address already in use in a python bot deployment — common causes and the actual fixes.

Fixing "Address Already in Use" When Redeploying a Python Bot

OSError: [Errno 98] Address already in use

This error shows up right when you least want it — usually right after a redeploy, right when you're trying to confirm a fix actually worked. Here's what it actually means, the most common causes in a bot deployment specifically, and how to resolve each one.

What This Error Actually Means
Cause 1: A Previous Process Didn't Fully Exit
Cause 2: Calling a Server-Starting Function Twice
Cause 3: Two Services Configured for the Same Port
Diagnosing Which Cause You Have
Fix: Killing a Leftover Process Locally
Fix: Checking for a Duplicate run() Call
Fix: Platform-Level Port Conflicts
Preventing This Going Forward
FAQs
Conclusion

What This Error Actually Means

At the OS level, only one process can bind to a given (host, port) combination at a time. This error means something is already listening on the port your bot is trying to use — whether that's a leftover process from a previous run, a genuine second server trying to start in the same process, or (less commonly) a platform-level conflict.

Cause 1: A Previous Process Didn't Fully Exit

The most common cause during local development: you stopped your bot with Ctrl+C, but the OS hasn't fully released the port yet, or a child process from a previous run is still alive in the background.

python main.py
# OSError: [Errno 98] Address already in use

Cause 2: Calling a Server-Starting Function Twice

If you're using StayPresent and see this error, it's worth checking whether staypresent.run() is being called more than once in the same process — accidentally, in a script that imports itself, or from two different code paths. As of recent StayPresent versions, this specific case is caught with a clearer RuntimeError explaining the actual issue before it ever reaches the OS-level bind attempt:

staypresent.run("bot.py")
staypresent.run("bot.py")  # RuntimeError: run() already called in this process

If you're seeing the raw OSError instead of that clearer message, you're likely on an older version, or the second "server start" is coming from somewhere other than StayPresent's own run().

Cause 3: Two Services Configured for the Same Port

On a hosting platform, this can happen if two separate deployments (or two processes within one deployment, like a leftover worker from a bad redeploy) are both configured to bind the same port.

Diagnosing Which Cause You Have

Locally, check what's actually using the port:

# macOS/Linux
lsof -i :8080

# Windows
netstat -ano | findstr :8080

If something unexpected shows up, that's your leftover process. If nothing shows up but the error persists, the cause is more likely a duplicate run() call within your own code.

Fix: Killing a Leftover Process Locally

# macOS/Linux — replace <PID> with the process ID from lsof
kill -9 <PID>

# Windows — replace <PID> with the PID from netstat
taskkill /PID <PID> /F

Fix: Checking for a Duplicate `run()` Call

Search your codebase for every call to staypresent.run() (or any raw app.run()/serve() call, if you're not using StayPresent). A common trigger is an entry-point script being imported by something else, causing top-level code — including a run() call — to execute a second time.

# Guard against accidental double-execution on import
if __name__ == "__main__":
    staypresent.run("bot.py")

Fix: Platform-Level Port Conflicts

If this only happens on your hosting platform and not locally, check for a leftover deployment or process still bound to the same port from a previous, incomplete redeploy. Most platforms fully tear down the old process before starting the new one, but a stuck or hung previous deployment can occasionally linger — a manual restart of the service (not just a redeploy) often clears this.

Preventing This Going Forward

Always guard your entry point with if __name__ == "__main__":.
Read the port from the environment (os.getenv("PORT", 8080)) rather than hardcoding it, so local testing and deployment don't collide over the same fixed value.
If you're on an older StayPresent version and want the clearer duplicate-call error instead of the raw OS error, upgrading is worth it specifically for that improved diagnostic.

FAQs

Does this mean my bot's code is broken?
Not necessarily — it's frequently an environment issue (a leftover process) rather than a logic bug, especially during local development.

Can two bots share the same port?
No — each service needs its own distinct port. If you're running multiple bots, they should share one StayPresent deployment (one port, multiple supervised bot processes) rather than each trying to bind the same port independently.

Why does StayPresent raise RuntimeError instead of letting this OS error happen?
A duplicate run() call is a common, easy mistake, and the raw OSError: Address already in use gives no indication of the actual cause. Catching it earlier with a clearer message saves the debugging time this tutorial is otherwise about.

Conclusion

"Address already in use" almost always traces back to one of three things: a leftover process from a previous run, an accidental duplicate call to whatever starts your server, or a platform-level conflict from an incomplete redeploy. Checking for a lingering process locally, guarding your entry point against double execution, and reading your port from the environment resolves the overwhelming majority of cases.

pip install staypresent[prod]

How to Give Your Bot a Public Uptime Page Your Users Can Check

John Wick — Sat, 22 Aug 2026 13:12:52 +0000

A tutorial for adding a public-facing uptime page to a Discord or Telegram bot, so users can check status themselves instead of asking you.

How to Give Your Bot a Public Uptime Page Your Users Can Check

"Is the bot down?" is one of the most common messages a bot maintainer gets, and answering it manually — every time, in every server, for every person who asks — doesn't scale past a handful of users. This tutorial covers giving your bot a public page people can check themselves, with real uptime history instead of just your word for it.

Why a Status Page Beats Answering DMs
Step 1: Install StayPresent
Step 2: Confirm the Default Page Is Already Live
Step 3: Customize the Page for Your Bot
Step 4: Share the Link Where Users Will Find It
Step 5 (Optional): Decide What's Public vs Admin-Only
Step 6 (Optional): Name Multiple Bots Clearly
Verifying What Users Actually See
FAQs
Conclusion

Why a Status Page Beats Answering DMs

Every time someone asks "is the bot down" and you have to manually check and reply, that's a small tax on your time — and if you're asleep, at work, or just not looking at Discord, the honest answer they get is silence, which reads as worse than an actual outage. A public page answers the question the moment it's asked, without you doing anything.

Step 1: Install StayPresent

pip install staypresent[prod]

Step 2: Confirm the Default Page Is Already Live

If you're already running your bot through StayPresent, you likely already have this — a status page is served automatically at /status the moment staypresent.run() starts:

import staypresent

staypresent.run("bot.py")
# https://your-app.example.com/status is already live

No extra code required for the basic version — uptime percentages, current status, and incident history are all generated automatically from data StayPresent already tracks.

Step 3: Customize the Page for Your Bot

import staypresent

staypresent.web.status(
    title="MyBot Status",
    copyright="MyBot Team",
    footer_links=[
        {"label": "Support Server", "url": "https://discord.gg/yourinvite"},
    ],
    mode="auto",
)

staypresent.run("bot.py")

Step 4: Share the Link Where Users Will Find It

Once it's live, the actual work is just making sure people know it exists:

Pin it in your support channel.
Add it to your bot's /about or /help command output.
Link it in your bot's Discord "About Me" or bio.

The page itself requires no maintenance after this — it updates live, automatically, with no manual step on your end.

Step 5 (Optional): Decide What's Public vs Admin-Only

By default, the page shows overall status, uptime, and plain-language incident descriptions to everyone — appropriate for a public audience. Deeper technical detail (exit codes, a recent log tail) is gated behind an admin key:

import os
import staypresent

staypresent.web.status(
    api_key=os.getenv("STATUS_ADMIN_KEY"),
)

Set your own key so only you (not a randomly generated, log-only key) can access that deeper view.

Step 6 (Optional): Name Multiple Bots Clearly

If your project actually runs several bots behind the scenes, label each one so the public page makes sense to someone who isn't familiar with your file structure:

staypresent.run(bots=[
    {"file": "main_bot.py", "services_name": "MyBot"},
    {"file": "backup_bot.py", "services_name": "Backup Bot"},
])

Verifying What Users Actually See

Open the page in a private/incognito browser window (so you're seeing it the way a logged-out visitor would) and confirm: the overall status is clear, uptime numbers are showing, and nothing sensitive (internal exit codes, log content) is visible without logging in as admin.

FAQs

Does this require my bot's own database?
No — everything on the page comes from data StayPresent already tracks for its own crash recovery; there's nothing separate to store or maintain.

Can users see exactly why the bot crashed?
Not by default — the public view shows that an incident happened and its plain-language status, not raw exit codes or logs. That detail is reserved for the admin view.

Will this slow my bot down?
No — serving the status page is a lightweight part of the same HTTP server StayPresent already runs for your platform's health check.

Conclusion

A public uptime page turns "is the bot down?" from a question only you can answer into something users can check themselves, any time, with real data instead of a guess. With StayPresent, the basic version needs no setup at all — /status is live the moment your bot is — and a few optional lines let you brand it and control exactly what's public.

pip install staypresent[prod]

Add Crash Recovery to Any Python Script in One Line

John Wick — Sat, 22 Aug 2026 13:10:44 +0000

A tutorial for adding automatic crash recovery to an existing python script with zero code changes to the script itself, using StayPresent.

Add Crash Recovery to Any Python Script in One Line

If you have a Python script that runs continuously — a bot, a scraper, a queue worker — and it currently just dies and stays dead the moment something throws an unhandled exception, this tutorial covers the fastest way to fix that: automatic restarts, with a sensible ceiling so a genuine crash loop doesn't run forever, and without touching a single line of the script itself.

Why Python Doesn't Restart Itself
Step 1: Install StayPresent
Step 2: Wrap Your Script (No Code Changes)
Step 3: Confirm It Restarts on a Real Crash
Step 4: Tune the Restart Behavior
Step 5 (Optional): Prevent Endless Crash Loops
Step 6 (Optional): Reset the Counter After Stability
What Counts as a "Clean Exit" (No Restart)
FAQs
Conclusion

Why Python Doesn't Restart Itself

Once an unhandled exception reaches the top of a Python script, the interpreter exits — nothing built into the language relaunches it. For a one-off script that's exactly the right behavior. For something meant to run indefinitely, it means a single uncaught error ends its uptime until a human manually restarts it.

Step 1: Install StayPresent

pip install staypresent[prod]

Step 2: Wrap Your Script (No Code Changes)

Say your script is worker.py. It stays completely untouched:

# main.py
import staypresent

staypresent.run("worker.py", web_server=False)

web_server=False is the key detail here — it gives you crash recovery with no HTTP server at all, which is exactly what you want for a script that doesn't need to satisfy a hosting platform's port requirement (a local script, a VPS process with no platform-level health check, or anything you're deliberately keeping off the network).

Run it:

python main.py

Step 3: Confirm It Restarts on a Real Crash

Test it deliberately — add a line that raises an exception partway through worker.py, run main.py, and watch the console. You should see the crash logged, a short delay, and the script relaunching automatically.

Step 4: Tune the Restart Behavior

staypresent.run(
    "worker.py",
    web_server=False,
    restart_on_crash=True,
    max_restarts=5,
    restart_delay=2.0,
)

max_restarts caps consecutive crashes — this is what stops a genuine crash loop (a missing config value, a bad credential) from restarting forever.
restart_delay adds a pause before each relaunch, useful if the crash was caused by something transient like a rate limit.

Step 5 (Optional): Prevent Endless Crash Loops

If your script hits max_restarts, staypresent.run() exits the whole process with the script's original exit code — this matters if you're also running under Docker or systemd, since it lets that outer layer's own restart policy act as a final backstop instead of the process quietly staying dead.

Step 6 (Optional): Reset the Counter After Stability

staypresent.run(
    "worker.py",
    web_server=False,
    max_restarts=5,
    restart_reset_after=60.0,
)

If your script stays up for at least 60 seconds after a restart, its crash counter resets to zero — so a script that crashes once every few days doesn't slowly creep toward its restart ceiling from unrelated, infrequent failures.

What Counts as a "Clean Exit" (No Restart)

An exit code of 0 is treated as intentional and never triggers a restart — useful if your script has legitimate logic to shut itself down on purpose (a scheduled one-time job, a manual stop condition):

import sys
# inside worker.py, when the script should stop on purpose
sys.exit(0)  # StayPresent will NOT restart this

Anything else — an unhandled exception, sys.exit(1), a segfault — is treated as a crash and restarted according to your configuration.

FAQs

Do I need an HTTP server for this to work?
No — web_server=False gives you crash recovery with zero HTTP surface, which is the right choice for a script that doesn't need to satisfy a platform health check.

Does this work for scripts with multi-line entry points, not just simple loops?
Yes — staypresent.run() launches your script as a subprocess exactly the way python worker.py would from the command line; it doesn't care what's inside it.

Can I add crash recovery to more than one script at once?
Yes — pass a list: staypresent.run(["worker1.py", "worker2.py"], web_server=False), each supervised independently.

Conclusion

Adding real crash recovery to an existing Python script doesn't require rewriting anything inside it — staypresent.run("worker.py", web_server=False) gives you automatic restarts, a sensible ceiling against crash loops, and a counter that resets after genuine stability, all without a single line of change to the script being supervised.

pip install staypresent[prod]

How to Detect a Frozen Python Bot (Not Just a Crashed One)

John Wick — Sat, 22 Aug 2026 13:10:18 +0000

A tutorial on detecting a python bot that's deadlocked or stuck without crashing, using heartbeat monitoring — with a working code example.

How to Detect a Frozen Python Bot (Not Just a Crashed One)

Most reliability setups only catch one kind of failure: the process exiting. A bot that's deadlocked, stuck on an API call with no timeout, or spinning in a broken loop never exits at all — it just sits there, "running" by every normal check, doing nothing useful. This tutorial covers detecting that specific failure mode, which standard crash recovery is structurally blind to.

Why Crash Detection Misses This
What a Frozen Bot Actually Looks Like From Outside
Step 1: Install StayPresent
Step 2: Add a Heartbeat Call to Your Bot's Loop
Step 3: Set a Heartbeat Timeout
Step 4: Choosing the Right Timeout Value
Step 5: Confirming It Works
What Happens When a Hang Is Detected
FAQs
Conclusion

Why Crash Detection Misses This

Standard restart logic reacts to a non-zero exit code. A deadlock or an infinite loop with a broken exit condition never produces one — the process is technically alive the entire time it's stuck, so nothing about exit-code-based monitoring ever triggers.

What a Frozen Bot Actually Looks Like From Outside

From a hosting dashboard's perspective, a frozen bot and a healthy one look identical: process running, memory allocated, no errors in the log because nothing is throwing one. The only real signal something's wrong is the complete absence of anything happening — no new messages processed, no API calls made, no progress at all.

Step 1: Install StayPresent

pip install staypresent[prod]

Step 2: Add a Heartbeat Call to Your Bot's Loop

In your bot script, call staypresent.heartbeat() once per iteration of your main loop:

# worker.py
import time
import staypresent

while True:
    staypresent.heartbeat()
    do_one_unit_of_work()
    time.sleep(1)

Place it near the top of each iteration — this way, if the work itself hangs, the next expected heartbeat is what catches it.

For an async, event-driven bot (discord.py, Pyrogram), call it from a periodic background task instead:

async def heartbeat_task():
    while True:
        staypresent.heartbeat()
        await asyncio.sleep(10)

Step 3: Set a Heartbeat Timeout

In your entry point, pass heartbeat_timeout to run():

# main.py
import staypresent

staypresent.run(
    "worker.py",
    heartbeat_timeout=30,
)

If worker.py goes more than 30 seconds without calling heartbeat(), StayPresent treats it as hung, terminates it, and restarts it through the normal crash-recovery pipeline.

Step 4: Choosing the Right Timeout Value

Set heartbeat_timeout comfortably above your normal iteration time, including realistic worst-case latency — a slow API call, a large batch. If your loop typically completes in 2–5 seconds, heartbeat_timeout=30 gives generous headroom for occasional slowness while still catching a genuine freeze well before it goes unnoticed.

Step 5: Confirming It Works

You can test this deliberately before relying on it in production — temporarily add a line that sleeps past your configured timeout without calling heartbeat(), and confirm the bot gets terminated and restarted as expected:

# temporary test — remove after confirming
import time
time.sleep(60)  # exceeds heartbeat_timeout=30

Watch the "staypresent" logger output; you should see the hang detected and the process restarted.

What Happens When a Hang Is Detected

The behavior mirrors a real crash exactly: the process is terminated, logged, and handed to restart_on_crash/max_restarts/restart_delay — the same recovery path, just triggered by silence instead of a bad exit code. On a recent StayPresent version, this also shows up as its own distinct "unresponsive" incident on the /status page, separate from a plain crash, so you can tell the two failure modes apart after the fact.

FAQs

Does every bot need heartbeat monitoring?
No — it's opt-in. A bot with no heartbeat_timeout set is only monitored for actual crashes, exactly as before.

Can different bots have different timeout values?
Yes — heartbeat_timeout is set per run() call (or per bot, if using bots=[...] with different configurations).

What if my bot legitimately has slow, variable-length operations?
Set the timeout based on your slowest realistic case, or call heartbeat() more granularly between sub-steps of a long operation rather than only once per full iteration.

Conclusion

A frozen process is a genuinely different failure mode from a crash, and it's invisible to anything only watching exit codes. staypresent.heartbeat() combined with heartbeat_timeout closes that gap — your bot proves it's actually making progress, not just technically running.

pip install staypresent[prod]

Deploy a Telegram Bot on Koyeb Without It Going Idle

John Wick — Sat, 22 Aug 2026 13:09:51 +0000

A step-by-step tutorial to deploy a Telegram bot on Koyeb with proper health checks and zero idle downtime, using StayPresent.

Deploy a Telegram Bot on Koyeb Without It Going Idle

Koyeb is a solid choice for hosting a Telegram bot — fast deploys, a generous free tier, support for both Git-based and Docker-based builds. But like most PaaS platforms, it expects your service to respond over HTTP, and a Pyrogram or python-telegram-bot script doesn't do that on its own. This tutorial walks through deploying a Telegram bot on Koyeb the right way, so it stays healthy and online instead of idling out.

Why Telegram Bots Go Idle on Koyeb
Step 1: Install StayPresent
Step 2: Wrap Your Bot's Entry Point
Step 3: Read Koyeb's Assigned Port
Step 4: Choose Your Deploy Path (Git or Docker)
Step 5: Set Koyeb's Health Check Path
Step 6 (Optional): Prevent Scale-to-Zero Idle
Verifying the Deployment
FAQs
Conclusion

Why Telegram Bots Go Idle on Koyeb

A Telegram bot polls or listens for updates from Telegram's own servers — it's an outbound connection, not an inbound one. Koyeb's health checks expect the opposite: something listening on a port it can reach. Without that, Koyeb has no way to distinguish "this bot is working perfectly" from "this bot is broken," and treats the deployment as unhealthy.

Step 1: Install StayPresent

pip install staypresent[prod]

# requirements.txt
staypresent[prod]
pyrogram

Step 2: Wrap Your Bot's Entry Point

Keep your bot's actual logic in bot.py, untouched. Create main.py:

import staypresent

staypresent.web.json({"status": "running"})

staypresent.run("bot.py")

Step 3: Read Koyeb's Assigned Port

import os
import staypresent

staypresent.web.json({"status": "running"})

staypresent.run(
    "bot.py",
    port=int(os.getenv("PORT", 8080)),
)

Step 4: Choose Your Deploy Path (Git or Docker)

Git-based (buildpack): Koyeb detects requirements.txt and builds automatically. Set the run command to:

python main.py

Docker-based (useful if your bot needs system packages like ffmpeg):

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "main.py"]

main.py is identical either way — only the deployment mechanism changes.

Step 5: Set Koyeb's Health Check Path

In Koyeb's service settings, point the health check explicitly at /health rather than the default:

staypresent.web.json({"status": "running", "version": "1.0"})
# /health still returns {"status": "ok"} independently of the above

This keeps platform health checks stable even if you later change what / serves.

Step 6 (Optional): Prevent Scale-to-Zero Idle

If your specific Koyeb service type is subject to scale-to-zero behavior you want to avoid, add a self-ping against your own public URL:

staypresent.cron("https://your-app.koyeb.app", interval=240)

Verifying the Deployment

Deploy, then check Koyeb's dashboard — the service should report healthy rather than cycling through restarts. Visit https://your-app.koyeb.app/health directly to confirm it returns {"status": "ok"}. On a recent StayPresent version, /status also gives you a live dashboard showing uptime over time, which is the easiest way to confirm the fix is holding rather than just working once.

FAQs

Does this work with python-telegram-bot instead of Pyrogram?
Yes — the fix is entirely about the entry point, not which Telegram library your bot uses internally.

Do I need Docker for a simple bot?
No — Git-based buildpack deploys handle standard Python dependencies fine; Docker is only needed for extra system-level packages.

Can I reuse this main.py if I later move to Render or Railway?
Yes — as long as PORT is read from the environment, the same file works unchanged across platforms following the same convention.

Conclusion

A Telegram bot going idle on Koyeb almost always comes down to a missing HTTP port, not a problem with the bot's own polling logic. Wrapping your existing bot in staypresent.run(), reading PORT dynamically, and pointing Koyeb's health check at /health solves it completely — Git-based or Docker-based, with no changes to your bot's actual code.

pip install staypresent[prod]

The Easiest Way to Add a Status Page Dashboard to Your Python Worker

John Wick — Thu, 20 Aug 2026 03:07:33 +0000

A tutorial on adding a live status page with uptime history and incident tracking to a python background worker in under five minutes.

The Easiest Way to Add a Status Page Dashboard to Your Python Worker

A background worker — a queue processor, a scheduled job runner, an API poller — usually has no visibility layer at all. It either works or it doesn't, and finding out which one requires checking logs or SSHing into wherever it runs. This tutorial covers the fastest way to give any Python worker a real status page: uptime history, incident tracking, and live status, without building any of it yourself.

What "Status Page" Actually Means Here
Step 1: Install StayPresent
Step 2: Wrap Your Worker Script
Step 3: That's It — Check /status
Step 4 (Optional): Customize the Page
Step 5 (Optional): Name Your Worker
Step 6 (Optional): Restrict Admin Detail
Deploying It Somewhere Real
FAQs
Conclusion

What "Status Page" Actually Means Here

This isn't a static "everything's fine" placeholder page. It's a real dashboard: per-service uptime percentages over 24 hours, 7 days, and 30 days, a merged incident history (crashes, restarts, recoveries), and live current status — all generated automatically from data your worker's supervisor already has, with nothing hand-built.

Step 1: Install StayPresent

pip install staypresent[prod]

Step 2: Wrap Your Worker Script

Your existing worker — worker.py, doing whatever it already does — doesn't need any changes:

# main.py
import staypresent

staypresent.run("worker.py")

Step 3: That's It — Check `/status`

This is genuinely the entire minimum setup. Run main.py, and a full status page is already live at http://localhost:8080/status — uptime tracking, incident history, everything, with zero additional configuration.

import staypresent

staypresent.run("worker.py")
# /status is live immediately, no extra code needed

Step 4 (Optional): Customize the Page

If you want it branded rather than generic:

import staypresent

staypresent.web.status(
    title="Data Pipeline Status",
    copyright="Your Team",
    footer_links=[{"label": "Docs", "url": "https://example.com/docs"}],
    mode="dark",
)

staypresent.run("worker.py")

Step 5 (Optional): Name Your Worker

By default, the status page shows your worker by its filename. For something more readable:

staypresent.run(
    "worker.py",
    services_name="Queue Processor",
    services_description="Handles incoming job batches",
)

Step 6 (Optional): Restrict Admin Detail

The public page shows overall status and uptime by default. If you want the deeper detail — exit codes, a recent log tail — locked behind a key rather than the auto-generated one:

import os
import staypresent

staypresent.web.status(
    api_key=os.getenv("STATUS_ADMIN_KEY"),
)

staypresent.run("worker.py")

Deploying It Somewhere Real

The exact same code works whether you're testing locally or deploying to Render, Railway, Koyeb, or a VPS — just make sure to read the platform's assigned port dynamically:

import os
import staypresent

staypresent.web.status(title="Data Pipeline Status")

staypresent.run(
    "worker.py",
    port=int(os.getenv("PORT", 8080)),
)

FAQs

Do I need a database for the uptime history?
No — everything shown is derived from data already tracked in-process for crash recovery; there's no separate storage to set up.

Can I add a status page to multiple workers at once?
Yes — pass a list or use bots=[...] in run(), and each worker gets its own row on the same page automatically.

Is the status page accessible without any login?
The overall status, uptime, and incident summaries are public by design, the same as any real status page. Deeper technical detail (exit codes, log tails) is gated behind an optional admin key.

Conclusion

Adding a real status dashboard to a Python worker doesn't require building anything — staypresent.run("worker.py") alone gets you a live page at /status with genuine uptime and incident tracking, and a couple of optional lines let you brand it and control what's public versus admin-only.

pip install staypresent[prod]

Deploying Multiple Python Bots to a Single Railway Container

John Wick — Thu, 20 Aug 2026 03:07:06 +0000

A tutorial for running two or more python bots on Railway inside one container and one service, with independent crash recovery for each.

Deploying Multiple Python Bots to a Single Railway Container

If you're running more than one Python bot — say, a Telegram ingestion bot and a Discord notification bot that share a database — deploying each as its own Railway service means double the hosting cost and double the configuration for something that's logically one unit. This tutorial covers deploying both bots inside a single Railway container, with each one still getting fully independent crash recovery.

Why Two Services Is Usually Overkill
The Naive Fix and Why It Falls Short
Step 1: Install StayPresent
Step 2: Structure Your Project
Step 3: Configure Multiple Bots in One Entry Point
Step 4: Read Railway's Assigned Port
Step 5: Deploy as a Single Railway Service
Verifying Both Bots Are Running
FAQs
Conclusion

Why Two Services Is Usually Overkill

Railway (like most PaaS platforms) charges per service, and each service needs its own configuration, environment variables, and deployment pipeline. If two bots are closely related — sharing a database, a queue, or just conceptually belonging to the same project — running them as two separate Railway services duplicates all of that for no real benefit.

The Naive Fix and Why It Falls Short

A common first instinct is a shell script:

python telegram_bot.py & python discord_bot.py & wait

This runs both, but there's no real process supervision here — if telegram_bot.py crashes, nothing restarts it, and you still haven't solved Railway's HTTP port requirement, since neither script opens one.

Step 1: Install StayPresent

pip install staypresent[prod]

# requirements.txt
staypresent[prod]

Step 2: Structure Your Project

project/
├── main.py
├── telegram_bot.py
├── discord_bot.py
├── requirements.txt

Both bot scripts stay exactly as they are — nothing about their internal logic needs to change.

Step 3: Configure Multiple Bots in One Entry Point

main.py:

import os
import staypresent

staypresent.web.json({"status": "running", "bots": 2})

staypresent.run(
    bots=[
        {"file": "telegram_bot.py"},
        {"file": "discord_bot.py"},
    ],
)

Each bot listed here is launched as its own subprocess, monitored independently — if telegram_bot.py crashes and restarts, discord_bot.py is completely unaffected and keeps running.

If each bot needs different environment variables:

staypresent.run(
    bots=[
        {"file": "telegram_bot.py", "env": {"ROLE": "ingestion"}},
        {"file": "discord_bot.py", "env": {"ROLE": "notifications"}},
    ],
)

Step 4: Read Railway's Assigned Port

import os
import staypresent

staypresent.web.json({"status": "running", "bots": 2})

staypresent.run(
    bots=[
        {"file": "telegram_bot.py"},
        {"file": "discord_bot.py"},
    ],
    port=int(os.getenv("PORT", 8080)),
)

Step 5: Deploy as a Single Railway Service

Set your Railway start command to:

python main.py

Deploy once. Both bots now run inside the same container, under one Railway service, with one hosting bill.

Verifying Both Bots Are Running

If you're on a recent StayPresent version, visit /status on your deployed URL — each bot appears as its own row, with its own uptime and restart count, so you can confirm both are actually healthy at a glance rather than guessing from Railway's own single-service view.

You can also give each bot its own lightweight endpoint for a quick manual check:

staypresent.web.json({"status": "online"}, path="/telegram")
staypresent.web.json({"status": "online"}, path="/discord")

FAQs

Does one bot crashing affect the other?
No — each bot in the bots list gets its own restart counter and its own monitoring thread, completely independent of the others.

Can I run more than two bots this way?
Yes — bots accepts as many entries as you need, each independently supervised.

Does this work the same way on Render or Koyeb?
Yes — the same main.py and multi-bot configuration work unchanged across any platform that follows the standard $PORT convention.

Conclusion

Running multiple related Python bots on Railway doesn't require multiple services. staypresent.run(bots=[...]) supervises each one independently — separate crash recovery, separate restart counters — while sharing a single container, a single port, and a single deployment.

pip install staypresent[prod]

How to Stop Your Discord Bot From Sleeping on Render's Free Tier

John Wick — Thu, 20 Aug 2026 03:06:12 +0000

A step-by-step tutorial to stop a discord bot from sleeping on Render's free tier — the real cause, the fix, and a working code example.

How to Stop Your Discord Bot From Sleeping on Render's Free Tier

You've deployed your Discord bot to Render's free tier, it worked for a bit, and now it's going offline — sometimes after a few minutes, sometimes randomly. This is one of the most common issues developers hit deploying a bot for the first time, and it has a specific, well-understood cause and a fix you can ship in under ten minutes.

Why This Happens on Render Specifically
Confirming This Is Your Actual Problem
Step 1: Install StayPresent
Step 2: Wrap Your Bot's Entry Point
Step 3: Read Render's Assigned Port
Step 4: Set Your Render Start Command
Step 5 (Optional): Prevent Inactivity Sleep Specifically
Verifying It Worked
FAQs
Conclusion

Why This Happens on Render Specifically

Render's free-tier web services are checked for health over HTTP, and free services also spin down after a period without incoming traffic. A discord.py bot connects outward to Discord's gateway — it never opens an HTTP port of its own, which is completely normal bot behavior. Render's health checker, seeing nothing respond on the expected port, has no way to know the bot is actually working fine internally. It just sees silence, and reacts accordingly.

Confirming This Is Your Actual Problem

If your bot's entry point goes straight into bot.run(TOKEN) with nothing else, and Render's dashboard shows the deployment as unhealthy or repeatedly restarting with no matching error in your bot's own logs, this is almost certainly it.

Step 1: Install StayPresent

pip install staypresent[prod]

Add it to your requirements.txt as well:

staypresent[prod]
discord.py

Step 2: Wrap Your Bot's Entry Point

Keep your existing bot code in bot.py completely unchanged. Create a new main.py:

import os
import staypresent

staypresent.web.json({"status": "running"})

staypresent.run("bot.py")

Step 3: Read Render's Assigned Port

Render injects a PORT environment variable — your app needs to bind to it dynamically, not a hardcoded value:

import os
import staypresent

staypresent.web.json({"status": "running"})

staypresent.run(
    "bot.py",
    port=int(os.getenv("PORT", 8080)),
)

Step 4: Set Your Render Start Command

In Render's service settings, set the start command to run your new entry point:

python main.py

Deploy. Render now has something to check on, and your bot's own logic — the actual discord.py code — didn't change at all.

Step 5 (Optional): Prevent Inactivity Sleep Specifically

Solving the port requirement alone stops Render from marking the deployment unhealthy. If Render's free tier is also spinning your specific service down after inactivity, add a self-ping targeting your own public URL:

import os
import staypresent

staypresent.web.json({"status": "running"})

staypresent.cron("https://your-app-name.onrender.com", interval=240)

staypresent.run(
    "bot.py",
    port=int(os.getenv("PORT", 8080)),
)

This has to target your actual onrender.com URL — pinging 0.0.0.0 or 127.0.0.1 never leaves the machine and won't count as external activity.

Verifying It Worked

After deploying, check Render's dashboard — the service should show as healthy rather than restarting in a loop. You can also visit your app's /health endpoint directly in a browser; it should return {"status": "ok"}. If you're on a recent version of StayPresent, /status shows a live status page with uptime history, which is a quick way to confirm the bot is staying up over time rather than just checking once.

FAQs

Do I need to change my bot's actual Discord logic?
No — bot.py stays exactly as it was. Only the entry point Render runs (main.py) is new.

Does this work for Telegram bots too?
Yes — the same pattern applies to any long-running Python process that doesn't open its own HTTP port, regardless of which platform's API it talks to.

Will this cost anything?
No — StayPresent is MIT licensed and free, and this setup doesn't require upgrading your Render plan.

Conclusion

A Discord bot sleeping on Render's free tier is almost always a missing HTTP port, not a bug in your bot. Wrapping your existing bot.py in staypresent.run(), reading Render's PORT variable, and optionally self-pinging your public URL solves it completely, with zero changes to your bot's actual code.

pip install staypresent[prod]

"I Could Just Build This Myself" — Sure, But Should You?

John Wick — Thu, 20 Aug 2026 03:04:37 +0000

Every piece of StayPresent is individually easy to build. Here's an honest look at what building it yourself actually costs versus installing it.

"I Could Just Build This Myself" — Sure, But Should You?

It's a fair reaction, and an honest one: a Flask server in a background thread isn't hard. Restart logic isn't hard. None of the individual pieces of what StayPresent does are conceptually difficult for a developer who already knows Python. The real question isn't whether you could build it — it's whether you should, given what it actually costs to build and maintain it properly.

The part that's easy to underestimate

The first 80% of a keep-alive server is genuinely quick to write — a Flask route, a background thread, done in twenty minutes. The remaining 20% is where the real time goes: handling a bot that crashes mid-restart-backoff during a shutdown signal without leaking a process. Making sure your logging doesn't clobber the root logger and break something unrelated. Deciding what "hung, not crashed" even means and building a mechanism to detect it. None of these are hard problems individually, but they're the kind of edge cases you only discover by hitting them in production, one at a time, over months.

What "building it yourself" actually costs

Say it takes a focused weekend to get a first version working. It probably will — the core idea is simple. What that weekend doesn't include is the six months of intermittent bug reports from your own deployment: the restart that didn't happen because of a race condition you didn't think about, the log line that got swallowed, the status page you don't have because that was never part of the plan and now feels like a whole separate project. The initial build is cheap. The maintenance is where a hand-rolled version quietly becomes a second, ongoing job.

What you get by not building it

import staypresent

staypresent.run("bot.py")

Every edge case above — the shutdown race condition, the isolated logging, hang detection, a working status page — already exists, already tested against real deployments, already maintained by someone whose actual job (at least for this piece) is making sure it keeps working. You get the twenty-minute version's simplicity with the six-months-later version's robustness, on day one.

There's no shame in not reinventing this

Plenty of genuinely excellent developers use tools like this specifically because they understand how the internals work — knowing how to build something yourself doesn't mean you should spend your limited time rebuilding it for the tenth time across your tenth project. Save the "build it myself" energy for the part of your bot that's actually unique — the part nobody else has already solved for you.

pip install staypresent[prod]

You could build this yourself. You probably have better things to build.

"What's the Catch?" — Why StayPresent Is Actually Free

John Wick — Thu, 20 Aug 2026 03:04:01 +0000

A tool that handles crash recovery, hang detection, and a full status page sounds like it should cost something. Here's why it doesn't, and won't.

"What's the Catch?" — Why StayPresent Is Actually Free

It's a reasonable question. A tool that handles crash recovery, hang detection, and generates a real status page — the kind of thing you'd expect to see behind a pricing page with a "Pro" tier — is, in fact, entirely free. Not a free tier that nudges you toward upgrading. Not a trial. Just free. Here's the honest answer to "what's the catch," because the skepticism is fair.

The MIT license, plainly stated

StayPresent is released under the MIT License — one of the most permissive open-source licenses that exists. In practice, that means: use it in a personal project, use it in something you're charging money for, modify it, redistribute it, all without paying anything or asking permission. There's no feature gate waiting behind a paywall, and no functionality quietly disabled unless you upgrade.

No account required, no data leaving your deployment

There's no account to create, no API key issued by a third party, no external service your bot phones home to. Everything — the web server, the crash recovery, the status page, the hang detection — runs directly inside your own deployment, on infrastructure you already control. There's genuinely nothing to charge for on the vendor side, because there's no ongoing service being provided from outside your own process.

Why "free forever" is actually plausible here

A lot of "free" developer tools eventually aren't, because they're subsidizing a hosted service somewhere — servers, bandwidth, support staff — and the free tier exists to fund a business built around eventually charging some of its users. StayPresent doesn't have that shape. It's a library, not a hosted service. There's no infrastructure cost scaling with your usage that would ever create pressure to start charging.

What you're actually trading

The honest trade isn't money — it's that you're running the supervision and monitoring yourself, inside your own deployment, instead of paying someone else to run it for you externally. For a solo bot developer or a small project, that's a genuinely good trade: you get real functionality, you keep full control, and you don't hand a third party visibility into your bot's uptime data.

Free, and worth checking yourself

pip install staypresent[prod]

You don't have to take this on faith — the source is open, the license is public, and there's nothing hidden to eventually find. Install it, read the code if you want to, and use it exactly the way the license says you can: however you want.

If People Pay for Your Bot, They Deserve to Know It's Actually Up

John Wick — Thu, 20 Aug 2026 02:52:46 +0000

Selling access to a bot or a Discord service? A public status page is one of the cheapest trust signals you can offer paying customers.

If People Pay for Your Bot, They Deserve to Know It's Actually Up

The moment a bot stops being a hobby project and starts being something people pay for — a premium tier, a subscription, a paid service inside a Discord server — the rules change. "It's usually fine" isn't good enough anymore. People handed you money on the expectation that the thing works, and when it doesn't, silence is the worst possible response.

What paying customers actually expect

Nobody expects 100% uptime — reasonable people understand things break. What they expect is to know when it does. A support DM answered with "yeah it's down, we're on it" lands completely differently than the same DM going unanswered for three hours while the customer wonders if they've been ignored, or worse, scammed. The information itself often matters less than how quickly and openly it's shared.

The gap between free and paid bots

A free bot going down for an hour is an inconvenience. A paid bot going down for an hour, with no visibility into why or when it'll be back, is a refund request — and, more damagingly, a screenshot in a review or a public complaint. The bar for reliability communication goes up the moment money changes hands, even if the bar for actual uptime doesn't move much at all.

A public status page does this for free

import staypresent

staypresent.web.status(
    title="MyBot Premium Status",
    footer_links=[{"label": "Support", "url": "https://mysite.com/support"}],
)
staypresent.run("bot.py")

This is live, automatically, the moment your bot is running — uptime history, incident timeline, current status, all generated from data StayPresent already has. No separate service, no separate bill, and critically, nothing extra for you to maintain when things are already stressful during an actual outage.

It answers the question before it's asked

The real value isn't during the outage — it's before anyone even has to ask. A customer who's curious can check /status themselves instead of DMing you. That's fewer interruptions for you during an actual incident, and a customer who feels like they have real visibility instead of having to take your word for it.

Trust is cheaper to build than to rebuild

Setting this up before you ever need it costs a few minutes. Rebuilding trust after a bad, poorly-communicated outage costs a lot more — refunds, churn, reviews you can't take back. If people are paying you for reliability, show them you're actually tracking it.

pip install staypresent[prod]

Your paying customers are already trusting you with their money. Give them somewhere to check that trust is warranted.

DEV Community: John Wick

How to Run a Python Bot on Fly.io Without It Sleeping

How to Run a Python Bot on Fly.io Without It Sleeping

Table of Contents

How Fly.io's Health Checks Work

Fly's Auto-Stop/Auto-Start Behavior

Step 1: Install StayPresent

Step 2: Wrap Your Bot's Entry Point

Step 3: Configure fly.toml

Step 4: Disable Auto-Stop for a Bot Machine

Step 5: Deploy

Verifying It's Actually Staying Up

FAQs

Conclusion

Fixing "Address Already in Use" When Redeploying a Python Bot

Fixing "Address Already in Use" When Redeploying a Python Bot

Table of Contents

What This Error Actually Means

Cause 1: A Previous Process Didn't Fully Exit

Cause 2: Calling a Server-Starting Function Twice

Cause 3: Two Services Configured for the Same Port

Diagnosing Which Cause You Have

Fix: Killing a Leftover Process Locally

Fix: Checking for a Duplicate run() Call

Fix: Platform-Level Port Conflicts

Preventing This Going Forward

FAQs

Conclusion

How to Give Your Bot a Public Uptime Page Your Users Can Check

How to Give Your Bot a Public Uptime Page Your Users Can Check

Table of Contents

Why a Status Page Beats Answering DMs

Step 1: Install StayPresent

Step 2: Confirm the Default Page Is Already Live

Step 3: Customize the Page for Your Bot

Step 4: Share the Link Where Users Will Find It

Step 5 (Optional): Decide What's Public vs Admin-Only

Step 6 (Optional): Name Multiple Bots Clearly

Verifying What Users Actually See

FAQs

Conclusion

Add Crash Recovery to Any Python Script in One Line

Add Crash Recovery to Any Python Script in One Line

Table of Contents

Why Python Doesn't Restart Itself

Step 1: Install StayPresent

Step 2: Wrap Your Script (No Code Changes)

Step 3: Confirm It Restarts on a Real Crash

Step 4: Tune the Restart Behavior

Step 5 (Optional): Prevent Endless Crash Loops

Step 6 (Optional): Reset the Counter After Stability

What Counts as a "Clean Exit" (No Restart)

FAQs

Conclusion

How to Detect a Frozen Python Bot (Not Just a Crashed One)

How to Detect a Frozen Python Bot (Not Just a Crashed One)

Table of Contents

Why Crash Detection Misses This

What a Frozen Bot Actually Looks Like From Outside

Step 1: Install StayPresent

Step 2: Add a Heartbeat Call to Your Bot's Loop

Step 3: Set a Heartbeat Timeout

Step 4: Choosing the Right Timeout Value

Step 5: Confirming It Works

What Happens When a Hang Is Detected

FAQs

Conclusion

Deploy a Telegram Bot on Koyeb Without It Going Idle

Deploy a Telegram Bot on Koyeb Without It Going Idle

Table of Contents

Why Telegram Bots Go Idle on Koyeb

Step 1: Install StayPresent

Step 2: Wrap Your Bot's Entry Point

Step 3: Read Koyeb's Assigned Port

Step 4: Choose Your Deploy Path (Git or Docker)

Step 5: Set Koyeb's Health Check Path

Step 6 (Optional): Prevent Scale-to-Zero Idle

Verifying the Deployment

FAQs

Conclusion

Step 3: Configure `fly.toml`

Fix: Checking for a Duplicate `run()` Call

Step 3: That's It — Check `/status`