DEV Community: John Wick

Run Python Bots Without Sleep On Render With StayPresent

John Wick — Thu, 23 Jul 2026 06:54:34 +0000

Deploy Python Bots on Render Without Sleep Using StayPresent

Render is one of the most popular free hosting platforms for small Python projects, but it comes with a well-known catch: free-tier web services spin down after a period of inactivity and require a fresh incoming request to wake back up. For a render python bot — a Discord bot, Telegram bot, or scraper — that "wake up" delay can mean minutes of downtime every time the service goes idle.

This guide covers exactly how Render's sleep behavior works, and how to eliminate it using StayPresent.

Understanding Render's Free Tier
Why HTTP Port Requirements Matter
Setting Up StayPresent for Render
Health Checks Explained
Self-Ping to Avoid Idle Sleep
Crash Recovery on Render
Full Working Example
Best Practices
Common Mistakes
FAQs
Conclusion

Understanding Render's Free Tier

Render's free web services sleep after roughly 15 minutes without incoming HTTP traffic. Once asleep, the next request has to spin the container back up before it responds, so real users (or a bot's own polling loop) experience a delay. Render also expects your web service to bind to a port it provides via the PORT environment variable — if nothing is listening there, Render's own health checks will consider the deploy unhealthy.

[Render Health Check] --HTTP GET--> [Your Service on $PORT]
                                        |
                                No response = unhealthy

Why HTTP Port Requirements Matter

A typical Telegram or Discord bot doesn't open an HTTP port — it just connects outward to Telegram's or Discord's API and waits for events. That's perfectly normal bot behavior, but it fails Render's expectations for a web service. The fix isn't to change how your bot works; it's to run a small HTTP server next to it, purely so Render has something to check.

Setting Up StayPresent for Render

Install the production extra so Waitress serves the app instead of Flask's development server:

pip install staypresent[prod]

Then in your entry point (commonly main.py):

import os
import staypresent

staypresent.web.json({
    "status": "running",
    "service": "my-telegram-bot"
})

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

Render's start command should simply run this file:

python main.py

Health Checks Explained

StayPresent automatically exposes /health, which always returns {"status": "ok"}. In Render's dashboard, you can point the service's health check path at /health instead of /, keeping your root route free to serve a status page, a JSON payload, or nothing more than the default {"message": "I'm Present"}.

Self-Ping to Avoid Idle Sleep

Render's sleep timer only cares about incoming traffic. If nothing external is hitting your service, staypresent.cron() can generate that traffic itself by pinging your own public URL on a schedule:

import os
import staypresent

staypresent.cron(
    "https://my-app.onrender.com",
    interval=240,  # every 4 minutes
)

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

This has to target your public URL — pinging 0.0.0.0 or 127.0.0.1 never leaves the machine, so it won't count as activity from Render's perspective.

You can also react to failures with a callback:

staypresent.cron(
    "https://my-app.onrender.com",
    interval=240,
    on_failure=lambda r: print(f"warm ping failed: {r['error']}"),
)

Crash Recovery on Render

Bots crash — a bad API response, a network blip, an unhandled exception. By default, StayPresent restarts your bot process automatically on a non-zero exit code:

staypresent.run(
    "bot.py",
    restart_on_crash=True,
    max_restarts=5,
    restart_delay=2.0,
    restart_reset_after=60.0,
)

max_restarts only counts consecutive crashes — if the bot stays up longer than restart_reset_after (60 seconds by default), the counter resets to zero. If restarts are exhausted, StayPresent exits the whole process with the bot's original exit code, so Render's own platform-level restart policy can take over as a last resort.

Full Working Example

import os
import staypresent

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

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

staypresent.run(
    "bot.py",
    port=int(os.getenv("PORT", 8080)),
    threads=8,
    restart_on_crash=True,
    max_restarts=5,
)

Best Practices

Point Render's health check at /health, not /, if your root route serves anything custom.
Set interval on cron() comfortably below Render's ~15-minute idle window — 4–5 minutes is a safe default.
Use the prod extra in any real deployment so Waitress handles concurrency instead of Flask's dev server.

Common Mistakes

Pinging the local bind address instead of the public Render URL. staypresent.cron("0.0.0.0", port=8080) only tests that your own server responds locally; it does nothing to prevent Render's sleep timer.
Forgetting to read $PORT from the environment. Render assigns this dynamically — hardcoding port=8080 will work locally but may not match what Render expects.
Assuming self-ping bypasses Render's hard limits. It only prevents inactivity sleep; it can't work around account-level suspensions or free-tier quotas.

FAQs

Does self-ping guarantee 24/7 uptime?
It prevents inactivity-based sleep, but final availability still depends on Render's own policies and limits.

Can I use the same setup on Railway?
Yes — Railway also injects $PORT automatically, so the exact same main.py works unchanged.

Do I need Waitress?
No, it's optional, but recommended for production traffic. Without it, StayPresent falls back to Flask's built-in server.

Conclusion

A render python bot doesn't have to sleep. Pair Render's $PORT requirement, StayPresent's built-in /health endpoint, an optional self-ping via cron(), and automatic crash recovery, and you get a bot that stays online, restarts itself when something goes wrong, and requires almost no boilerplate to set up.

pip install staypresent[prod]

Full Guide on How to Keep Python Bot Alive with StayPresent

John Wick — Thu, 23 Jul 2026 06:52:51 +0000

The Complete Guide to Keeping Python Bots Alive Using StayPresent

If you've ever deployed a Telegram bot, Discord bot, or background worker on a free hosting tier, you've probably watched it die a slow, quiet death a few minutes after your last request. One moment it's responding instantly, the next it's completely unresponsive until someone happens to poke it again. This is the single most common problem developers run into when they try to keep a python bot alive on modern cloud platforms, and it has a well-understood cause and a genuinely simple fix.

This guide walks through why it happens, and how a small package called StayPresent solves it with one line of code.

Why Python Bots Stop Running
How Free Hosting Platforms Actually Work
What a "Keep-Alive Server" Really Is
Introducing StayPresent
Installing StayPresent
Your First Keep-Alive Bot
The Built-In Health Endpoint
Deploying to Render
Best Practices
Common Mistakes
FAQs
Conclusion

Why Python Bots Stop Running

Most Python bots — Telegram bots built with Pyrogram or python-telegram-bot, Discord bots built with discord.py, scrapers, automation scripts — are designed to run forever in a loop. They don't naturally open an HTTP port; they just sit there, listening for events or polling an API.

The problem is that most free-tier hosting providers were never built for that kind of workload. They were built to serve web traffic. So they monitor for one specific signal: is something listening on an HTTP port? If nothing answers on that port for a while, the platform assumes your service is idle, and it either spins the container down or marks it unhealthy and restarts it — often destroying whatever in-memory state your bot was holding onto.

How Free Hosting Platforms Actually Work

Platforms like Render, Railway, Koyeb, and similar services generally fall into two buckets:

Web services, which expect an HTTP server bound to a PORT environment variable, and which the platform actively health-checks.
Background workers, which don't need a port, but often come with stricter limits or aren't available at all on the free tier.

If you deploy a bot as a web service without an HTTP server, the platform will typically flag it as unhealthy because nothing responds on the expected port. This is the root cause behind most "my bot randomly stops working" reports you'll find in developer communities.

What a "Keep-Alive Server" Really Is

The fix is conceptually simple: run a tiny HTTP server alongside your bot, purely so the hosting platform has something to talk to. The server doesn't need to do anything meaningful — it just needs to exist and respond to requests.

Developers have hacked this together for years with a few lines of raw Flask, spun up in a background thread next to their bot's main loop. It works, but it means every bot ends up with its own copy of the same boilerplate: server setup, threading, process management, and eventually crash recovery once the bot starts failing in production.

That repeated boilerplate is exactly what StayPresent replaces.

Introducing StayPresent

StayPresent is a lightweight Python package that runs a Flask-powered HTTP server next to your bot script, with optional production-grade serving through Waitress. Instead of writing your own threading and process-management code, you call one function and StayPresent handles the rest — starting the server, running your bot script as a subprocess, and restarting it automatically if it crashes.

It's built specifically for platforms that require an active HTTP port, including Render, Railway, Koyeb, and Heroku, and it works just as well inside Docker or on a plain VPS.

Installing StayPresent

Standard installation:

pip install staypresent

For production deployments, install the prod extra, which pulls in Waitress and suppresses Flask's development-server warning:

pip install staypresent[prod]

Your First Keep-Alive Bot

Here's the entire setup needed to keep a bot alive:

import staypresent

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

staypresent.run("bot.py")

That's it. staypresent.run() starts the HTTP server and launches bot.py as a subprocess at the same time. If you don't configure a response at all, StayPresent defaults to returning {"message": "I'm Present"} on the root route, so even the laziest possible setup still gives the platform something to check.

You can also serve plain text:

staypresent.web.text("Service Operational")

Or a full HTML page, read fresh from disk on every request, along with any CSS/JS/images sitting next to it:

staypresent.web.html("templates/index.html")

The Built-In Health Endpoint

StayPresent automatically exposes a dedicated /health route that always returns {"status": "ok"}. This is separate from whatever you've configured at /, so you can use / for a human-facing status page and /health specifically for platform health checks and uptime monitors.

Deploying to Render

Render assigns the port to listen on through the PORT environment variable, so your entry point should read it dynamically:

import os
import staypresent

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

Your start command is simply:

python main.py

Railway follows the exact same pattern since it also injects $PORT automatically.

Best Practices

Always bind to 0.0.0.0, not 127.0.0.1, so the platform's health checker can actually reach the server. This is StayPresent's default.
Read the port from the environment on any platform that assigns one dynamically.
Keep restart_on_crash enabled (it's on by default) so a bad exception in your bot doesn't take the whole service down permanently.
Isolate your logging — StayPresent logs under its own "staypresent" logger and never touches your root logger, so you can freely raise or lower its verbosity without affecting your bot's own logs.

Common Mistakes

Passing a bare string to bot_args instead of a list. bot_args="--verbose" will not behave the way you expect — pass ["--verbose"].
Assuming a keep-alive server prevents platform shutdowns. It only stops the platform from marking your service idle. It won't override hard usage limits, account suspensions, or free-tier quotas.
Forgetting the health endpoint exists. Some platforms let you point their health check specifically at /health instead of /, which is worth doing if your root route serves a dashboard.

FAQs

Does StayPresent replace Flask?
No — it wraps Flask (and optionally Waitress) to handle the hosting boilerplate for you.

Does it host my application?
No. It runs inside whatever hosting environment you've already chosen; you still need to deploy to Render, Railway, a VPS, or similar.

Does it keep my app alive forever?
No single tool can guarantee that. StayPresent solves the HTTP-port problem and can optionally self-ping to avoid inactivity sleep, but it can't override hard platform limits.

Conclusion

Keeping a Python bot alive on modern cloud platforms almost always comes down to one thing: giving the platform an HTTP port to check. StayPresent turns that requirement from a recurring chore into a single line of code, while also handling crash recovery and production-grade serving along the way.

If you're tired of rewriting the same Flask keep-alive snippet for every new bot, install StayPresent and get back to building the bot itself.

pip install staypresent[prod]

DEV Community: John Wick

Run Python Bots Without Sleep On Render With StayPresent

Deploy Python Bots on Render Without Sleep Using StayPresent

Table of Contents

Understanding Render's Free Tier

Why HTTP Port Requirements Matter

Setting Up StayPresent for Render

Health Checks Explained

Self-Ping to Avoid Idle Sleep

Crash Recovery on Render

Full Working Example

Best Practices

Common Mistakes

FAQs

Conclusion

Full Guide on How to Keep Python Bot Alive with StayPresent

The Complete Guide to Keeping Python Bots Alive Using StayPresent

Table of Contents

Why Python Bots Stop Running

How Free Hosting Platforms Actually Work

What a "Keep-Alive Server" Really Is

Introducing StayPresent

Installing StayPresent

Your First Keep-Alive Bot

The Built-In Health Endpoint

Deploying to Render

Best Practices

Common Mistakes

FAQs

Conclusion