![[Step 4-A-3/3] Keeping It Awake — The Free-Tier Sleep Problem and What to Do About It (Office Worker Edition)](https://lifetechhack.com/wp-content/uploads/2026/09/expert-1027-sleep.png)
📌 Expert Workflows · Step 4: Cloud Deployment and Its Limits · Edition A (Office Worker) · Part 3 of 3
What was tested: the standalone HTTP diagnostic in Step 4 was tested locally. It intentionally reports Telegram and AI as not tested. No cloud deployment, idle wake-up or live bot delivery was tested for this article. The troubleshooting scenario is illustrative, not an author deployment report.
🎯 Where This Fits
Parts 1 and 2 covered preparation, service selection and configuration. This final part helps an operations coordinator decide whether a hosting arrangement is suitable for a team bot. You can make that decision before deploying or paying for anything.
Separate delay from loss. A stopped polling process cannot fetch new updates, but that does not mean each message immediately disappears. This guide shows what can wake a web service, what an HTTP health response actually proves, and what evidence you need before blaming sleep for missing replies.
The outcome is a hosting decision and a test record: what delay can your team tolerate, how will you detect failed delivery, and what fallback will you use? A quick reply during setup is not a reliability measurement.
👤 Who’s Walking You Through This
Edition A — Dan, operations coordinator. Dan is a fictional composite reader. His problem is a bot that answers during setup but is silent later. We will identify observations that distinguish a stopped process, delayed delivery and failed processing.
Use the Expert Workflows roadmap for available lessons. Unpublished alternative editions are not required for this exercise.
🛠️ Before You Start
- Understand the polling bot and configuration checks from the earlier parts; a live deployment is optional
- For the local HTTP exercise: Python and aiohttp; no bot token or AI key required
📝 Step 1: Why Free Tiers Sleep
Render Free Web Services stop after 15 minutes without inbound traffic and can wake on a new incoming request, with startup taking about a minute. This is a service-specific limit, not a rule for all free hosting or for paid workers. See Render’s free-service documentation.
A visitor can trigger an HTTP request to a website. Someone messaging a polling bot on Telegram does not directly send an HTTP request to your hosting URL. That difference matters more than the word “free.”
The existing bot uses polling. Before considering idle behaviour, remember that a polling-only script does not meet a Web Service’s listening-port requirement. Part 2’s paid worker route avoids that mismatch; it does not use the free web-service idle rule.
📝 Step 2: Why Sleep Breaks a Polling Bot Specifically
Recall how your bot works: it polls. It repeatedly asks Telegram “any new messages?” That asking is an active process — it only happens while your bot is awake and running.
When the polling process stops, it stops fetching updates. Telegram temporarily queues incoming updates, but does not keep them longer than 24 hours. See Telegram’s update delivery rules. Outbound polling does not itself supply the inbound HTTP request needed to wake a sleeping Render web service.
If a polling loop has been combined with an HTTP server, a request to that server can wake its web service. The next Telegram message alone does not do that. If the application resumes within the retention window, pending updates may still be fetched; whether they are processed also depends on offsets, filters, restart options and application errors.
A silent reply is a symptom, not a diagnosis. Check whether the process was running, whether an update reached the handler and whether the handler completed. Sleep is one possible cause; an invalid key, a competing polling instance or an AI request failure can also produce silence.
📝 Step 3: The Honest Options
Choose a route based on your bot’s required response time and the work you are prepared to maintain. The options below are alternatives, not successive steps you must all implement.
Option 1 — Keep polling on a paid Background Worker. This matches the current bot implementation. Render workers have no Free instance and do not need to expose an HTTP port. A continuously running worker still needs error handling and monitoring; it is not an uptime guarantee. See Background Workers.
Option 2 — Use local polling for learning or explicitly limited hours. If you are not ready to pay or redesign, run the existing bot locally when needed and tell users when it is unavailable. A health endpoint plus periodic pings is sometimes used with free web services, but it neither removes usage limits nor proves bot delivery. This lesson does not set up a keep-awake service or recommend it as a reliability guarantee.
Option 3 — Build a webhook application. Telegram sends incoming HTTPS requests to your endpoint, which can trigger a sleeping web service to wake. Cold-start delay, failed requests and retries remain possible. This requires a real webhook handler, validation of Telegram’s secret-token header, duplicate-update handling and a durable processing strategy. Polling and webhook delivery cannot be used simultaneously for the same bot. See Telegram’s webhook specification. This article does not supply that implementation or claim it eliminates message loss.
Option 4 — Use paid web hosting for an actual HTTP/webhook application. Paying for a web service removes its free-instance idle limitation, but does not convert polling-only code into an HTTP app. Check the current compute price for the service you choose and any separate AI charges. Decide whether the cost is justified by your own usage; no time saving or fixed monthly total is assumed here.
📝 Step 4: Test What a Health Endpoint Really Proves
The earlier short snippet defined a function but did not start it, and omitted import os. The complete exercise below starts a standalone HTTP server. It deliberately runs without a bot, so you can see why a green HTTP check is not an end-to-end bot test. Save it as health_demo.py, install python -m pip install aiohttp==3.14.3, and run python health_demo.py. Open http://127.0.0.1:10000/health locally. Stop with Ctrl+C.
"""Standalone local HTTP liveness lesson, not a Telegram bot or webhook."""
import os
from aiohttp import web
async def health(request):
return web.json_response({'http': 'ok', 'telegram': 'not_tested', 'ai': 'not_tested'})
def create_app():
app = web.Application()
app.router.add_get('/health', health)
return app
if __name__ == '__main__':
raw_port = os.getenv('PORT', '10000')
try:
port = int(raw_port)
if not 1 <= port <= 65535:
raise ValueError
except ValueError:
raise SystemExit('PORT must be an integer from 1 to 65535')
web.run_app(create_app(), host='127.0.0.1', port=port, access_log=None)
Expected response: {"http":"ok","telegram":"not_tested","ai":"not_tested"}. The HTTP 200 establishes only that this handler answered. This local example binds to loopback and is not a Render deployment or a webhook handler. Do not replace your bot’s start command with it and assume the bot will run alongside it.
Local verification, 13 September 2026: Python 3.11.4 / aiohttp 3.14.3. An actual local HTTP request to /health returned 200 with both external services marked not tested; an unknown route returned 404. Separate process runs with PORT values abc, 0 and 65536 exited with the expected configuration error. Five cases passed. The local server was stopped after testing. No cloud sleep behaviour was measured.
Illustrative diagnosis: the scenario below explains how to investigate missing replies. It is not a measured incident, and the apparent pattern alone cannot establish a cause.
⚠️ Dan’s Error Log #4 — The bot that missed the morning’s messages
(Teaching scenario — a common mistake reconstructed for learning, not a personal claim.)
🔴 BEFORE
BEFORE: after an idle period, only one of three test messages receives a reply. The initial assumption is that the first two were lost because the host slept.
🤔 Cause
Possible causes include delayed fetching, intentional backlog dropping at startup, handler errors, a second polling consumer, or an AI request that failed after the update was received. A short sleep by itself does not explain permanent loss of fresh queued updates. Compare send times with process start and handler logs, and inspect whether startup code discards pending updates.
If two recent messages were skipped but a later one succeeded, investigate the processing path. Do not present that sequence as proof of an idle wake-up. Keep private content and token-bearing URLs out of diagnostic records.
🟢 AFTER
AFTER: choose a supported service type, run a controlled idle test, and record where each message reached the pipeline. Use a paid worker if you want to keep the current polling code continuously available. A webhook migration is a separate engineering change that must be tested, including cold starts and duplicate deliveries.
Tell colleagues the availability you can support and provide an alternative for urgent work. Do not promise working-day reliability based on a single successful message or health check.
Diagnostic lesson: opening a web URL during an idle test may itself wake the service and change the condition you intended to observe. Sending a message to a polling bot does not provide that inbound web traffic. Record what you touched, not just whether a reply appeared.
⚠️ Don’t Close the Tab Yet
Write down the requirement first. For a learning bot, manual startup and delayed replies may be acceptable. For a team tool, specify a tolerable delay and a fallback before choosing hosting. For example, “demonstration only; no urgent requests” is a clear boundary, not a reliability claim.
Count maintenance as well as hosting cost. Restarts, monitoring, queue handling and incident response remain work whichever plan you choose. Use your own measured time and workload rather than assuming a particular paid plan will save hours.
Use non-sensitive test messages. If your bot forwards text to an AI provider, explain that data path to users and keep workplace-confidential material out of a demonstration. This local health exercise sends no messages to Telegram or an AI provider.
✅ What You Can Now Decide
You can distinguish a polling worker from an HTTP application, separate queued-message delay from proven loss, and explain why an HTTP 200 does not establish Telegram or AI health. The available test result is the local HTTP exercise; the hosting and delivery limits come from the linked primary documentation.
A deployment is verified only after you test your own running service. If you have not deployed, record “local HTTP exercise complete; cloud delivery not tested.”
💡 If You Want to Push It
Extend monitoring only when you know what each signal means. HTTP liveness, time of last handled update and a controlled end-to-end reply test answer different questions. Avoid logging message bodies or credentials, and do not call a paid AI API on every health request.
❓ Your Turn
On a disposable deployment, establish one successful baseline reply and its time. Leave it idle for longer than the documented threshold without opening its HTTP URL or running a pinger. Send a uniquely labelled, non-sensitive test message and record delivery, handler and reply times where available. Then inspect host events. A slow reply alone does not prove a cold start, and a fast reply alone does not identify your hosting plan. If no service is deployed, use the worksheet below as a plan rather than filling in invented results.
Keep a delivery record, not just a green badge
| Record | What to enter |
|---|---|
| Setup | Service type, plan, deployment version, polling or webhook |
| Idle conditions | Start/end time; any HTTP visits, pings or deploys |
| Test path | Message label and send time; handler time; reply time |
| Diagnosis | Observed host event or error; competing explanations |
| Decision | Accept delay, change service, or investigate further |
Use “not observed” for missing evidence. Do not infer that a message was lost merely because you did not receive a reply.
🔗 What’s Next
This completes the configuration and hosting-decision lessons for this edition. A production webhook migration, sustained uptime measurement and cloud deployment remain separate work.
Next is Step 5: AI Draft + Human Edit, a separate content-production series. The Expert Workflows roadmap lists the available course material.
✍️ About the author & how this was made
Written for Life Tech Hack by G. Troy with AI-assisted editing and a local HTTP experiment. The results above describe only that experiment, not an author cloud-deployment experience.
See the site’s editorial standards. Recheck the linked hosting documentation before choosing a service.