BotNetwork

How to keep a bot online 24/7 for free (and what "free" really costs)

Free hosting works best when the bot does not need to stay awake. Design for webhooks first, and "always on" stops being a hosting problem.

Published 4 min read

The key idea: make the bot event-driven

A bot that holds a WebSocket open (Discord Gateway, Slack Socket Mode) or loops on Telegram getUpdates needs a process running every second of the day. A bot that receives webhooks only runs when a message arrives. Most free tiers are generous with requests and stingy with always-on compute, so the cheapest way to stay online is to switch to webhooks wherever the platform allows it:

  • Telegram: call setWebhook with an HTTPS URL and a secret_token.
  • Discord: handle slash commands and buttons as HTTP interactions by setting an Interactions Endpoint URL. You only need the Gateway to read ordinary messages or presence.
  • Slack: use the Events API over HTTP instead of Socket Mode.
  • WhatsApp Cloud API: webhooks are the only option anyway.

Option 1: webhook bot on a serverless free tier

Edge and serverless platforms bill per request, and several include a free allowance that a small bot will not exhaust. The Cloudflare Workers free plan, for example, documents a daily request quota and a per-request CPU limit; a bot that verifies a signature, reads some state and calls sendMessage fits comfortably. Pair it with a free database tier (D1, KV or a hosted Postgres free plan) for state.

What makes it work:

  1. Acknowledge fast, then do the work. Use ctx.waitUntil or a queue for anything slow.
  2. Keep secrets in the platform's secret store.
  3. Watch your quotas; most dashboards show usage per day.

Our guide to bots on Cloudflare Workers walks through a full Telegram bot, and the Cloudflare Workers Telegram template is a ready-to-deploy ZIP.

Option 2: an always-free virtual machine for gateway bots

If you truly need a persistent connection, look for providers with always-free compute rather than time-limited trials. At the time of writing, Oracle Cloud's Always Free tier includes Arm-based Ampere A1 compute, and Google Cloud's free tier includes one e2-micro VM per month in specific US regions. Both come with conditions (regions, capacity, account verification with a card), so read the terms.

Run the bot under systemd with Restart=always, or in a container with a restart policy, so it comes back after crashes and reboots.

Option 3: scheduled jobs on CI runners

For bots that post on a schedule (a daily digest, a feed watcher), a scheduled workflow on a CI service can be enough. Know the limits: GitHub documents that scheduled workflows can be delayed during periods of high load, and that in public repositories they are disabled automatically after 60 days without repository activity. That is fine for a digest and wrong for anything interactive.

Traps that take free bots offline

  • Sleeping services. Some free container plans spin down after a period without inbound HTTP traffic. A gateway bot on such a plan silently disconnects. Pinging it to keep it awake usually breaks the provider's terms.
  • Plans that disappear. Heroku ended its free dynos in November 2022, and others have changed plans since. Keep your deployment portable: a Dockerfile and environment variables, not a platform-specific setup you cannot move.
  • Polling from two places. Telegram returns 409 Conflict when two processes call getUpdates or when a webhook is set. When moving hosts, stop the old one first.
  • No monitoring. A free bot that is down for a week is worse than a paid one that pages you.

Free monitoring that is good enough

  • A /healthz endpoint that checks the database and returns 200.
  • An external uptime checker on a free plan hitting that endpoint every few minutes.
  • For Telegram, getWebhookInfo shows last_error_message and the number of pending updates: check it in your health endpoint.
  • Log every failed send with the platform's error description.

When to stop using free

Pay when users depend on the bot, when you need an SLA, or when you spend more time fighting limits than building. A small VPS or a paid serverless plan costs less than the time you lose to an unreliable free one.

Sources