Why Free Telegram Bot Hosting Fails, and Exactly When

Free hosting for Telegram bots works. Genuinely — a lot of useful bots run on free tiers and always will.

It also fails, and it fails at a specific, predictable point that has nothing to do with running out of CPU. Knowing where that point is lets you stay free as long as it is safe and move before it costs you something.

The failure that matters: sleep on idle

Nearly every free tier suspends an instance after a period of inactivity. Render's own docs are the concrete case: a Free web service spins down after 15 minutes without inbound traffic, and spinning back up "takes about one minute" (render.com/docs/free, checked September 2026). Other providers wake faster; we have not measured them, so check your own provider's docs rather than assuming seconds.

For a web app that is a slow page load. For a Telegram bot on webhooks, it is a delivery backlog — and, past 24 hours, data loss.

Telegram POSTs an update to your endpoint. Your instance is asleep. The request fails or times out. From the documentation: "In case of an unsuccessful request (a request with response HTTP status code different from 2XY), we will repeat the request and give up after a reasonable amount of attempts."

Read the parenthetical. Telegram defines an unsuccessful request as one that came back with a non-2XY HTTP status. A slow cold start that eventually answers 200 is a success — the user just waited. How a refused connection or a timeout is classified, and what "a reasonable amount of attempts" means, are not documented. We don't know those numbers.

After those attempts Telegram stops knocking — but it does not throw the update away. The docs say incoming updates are "stored on the server until the bot receives them either way, but they will not be kept longer than 24 hours." The update waits in the queue, visible as pending_update_count in getWebhookInfo, and is delivered once your endpoint answers again; you can also pull it with getUpdates after a deleteWebhook. What a sleeping instance buys you is delay, not deletion — until the 24-hour ceiling, or until you clear the queue yourself with drop_pending_updates.

They see silence, and you see nothing — unless you look. getWebhookInfo is where Telegram writes it down: a rising pending_update_count alongside a fresh last_error_date and last_error_message is the signature of an endpoint that was asleep when an update arrived.

The cruel detail: this happens during quiet periods, because quiet is what triggers the sleep. Your bot is least reliable exactly when you are least likely to be watching, and the messages that sit queued are the ones from users arriving outside your busy hours.

Long polling largely sidesteps this — your process reaches out, and updates queue at Telegram while you are away, for up to 24 hours. But a sleeping instance is not polling either, so you still need something keeping it awake.

The other four

Ephemeral storage. Local files disappear on restart. Fine if all state lives in a database. Fatal if you cached something you assumed would persist — session state, downloaded media, a "temporary" file that became load-bearing.

No reliable scheduling. Drip sequences, renewal checks, dunning and grace-period removals all need something running on a clock. A suspended instance fires no timers. Sequences stall silently and resume at odd intervals, which is worse than not running them.

Bandwidth caps. Media-heavy bots hit these. Note the mitigation: sending an existing file_id costs you nothing and has no size limit, while re-uploading the same file every time is bandwidth you are paying for unnecessarily.

The migration cost. The real one. Moving off free hosting happens under pressure, with live users, usually right after something broke. Everything is harder then.

Exactly when to leave

Not a volume threshold. A capability threshold. Leave free hosting the moment any of these is true:

You take payments. A dropped update during a payment flow is a customer who paid and received nothing. That is a refund and a support ticket, and it is the kind of failure that costs more than the hosting you were saving on.

You run scheduled work. Sequences, renewals, dunning, timed removals. These need an always-on process, full stop.

You use webhooks. Cold starts turn every quiet period into a delivery backlog, and anything still undelivered 24 hours later is gone. Check getWebhookInfo before deciding this is theoretical.

Users notice silence. The moment your bot stopping is something anyone would complain about, it needs to not stop.

You have data you cannot lose. Ephemeral storage and free-tier databases without backups are not where that belongs.

Notice that "high traffic" is not on the list. Free tiers usually have plenty of capacity. It is reliability and persistence you outgrow, not throughput.

Where free is genuinely fine

Development and testing
Personal or hobby bots where downtime costs nothing
Low-traffic bots using long polling, with no scheduled work
Prototypes still proving an idea

If you are here, stay. Do not spend money to fix a problem you do not have.

Making free work while you are on it

Use long polling, not webhooks. It bounds the cold-start data-loss category rather than removing it: updates wait for you in Telegram's queue, but not beyond 24 hours. And it needs no certificate.

Keep all state in a managed database, even a free one. Never rely on local disk.

Keep the instance awake if the provider allows it — an external uptime pinger every few minutes. Check the terms; some providers explicitly prohibit this, and getting suspended is worse than sleeping.

Reuse file_ids rather than re-uploading media. Free bandwidth and faster sends.

Monitor update arrival and getWebhookInfo, not process health. It is the check that reveals whether sleep is costing you messages — and it works identically on free and paid hosting.

What leaving costs

A small always-on instance and a managed database with backups runs roughly $10–$30/month. That is the entire fix for every problem in this article.

It is the highest-value money in your whole stack — cheaper than the refund, the lost customer, or the evening spent migrating under pressure. See what hosting actually costs for the full picture at each scale.

The summary

Free hosting fails on persistence and wakefulness, not capacity.

Stay free while your bot is an experiment. Move the moment it takes money or runs a clock — and move calmly, before something forces you to.

API retry behaviour quoted from Telegram's Bot API documentation, verified September 2026. Provider behaviour varies; check your own terms.