Set up a Telegram bot that monitors website uptime
Reliable monitoring turns an invisible outage into a clear, time-stamped alert that a team can act on. A practical way to set up a Telegram bot that monitors website uptime is to combine an independent uptime-checking service with Telegram’s Bot API. The checker tests your website, while the bot turns status changes into concise messages for a private channel or incident group.
For Australian businesses, that pairing is useful across a geographically spread market. A Melbourne retailer may need its checkout watched, while a Sydney software team cares more about an API, and a Perth organisation may rely on a regional office portal. These situations reflect the local market, where many customers encounter Australian businesses through .com.au or .au domains rather than overseas-facing websites.
The implementation has three moving parts: a monitor with an API or webhook, a Telegram bot created through BotFather, and a small handler that validates incoming alerts and calls Telegram’s sendMessage method. Running that handler outside the origin infrastructure keeps monitoring independent from the infrastructure it supervises.
Define what downtime means
Start by listing the endpoints that represent business availability, not every URL on your site. At minimum, check the public homepage with an HTTPS request and a sensible timeout. Add the login page, checkout endpoint or critical API only when you can protect it against frequent false alarms.
Agree on what counts as down. A non-success HTTP status, a failed TLS handshake, a timeout and a missing DNS record have different causes, so preserve the check type, response time, status code and error message in each alert. This makes a Telegram message useful for diagnosis rather than just an interruption notice.
Choose a checking interval that matches the cost of downtime and the load your target can tolerate. A minute-by-minute external check is often enough for a public website, while a critical API may justify closer spacing. Use multiple locations or providers when regional routing matters, and avoid checks so frequent that they resemble a denial-of-service test.
Create and secure the Telegram bot
Open Telegram and start a chat with BotFather. Run /newbot, choose a readable display name and a unique username ending in bot, then copy the access token BotFather returns. The token is a credential: store it in an environment variable or a secrets manager, never in source code, screenshots or a shared incident channel.
If you prefer offline material, check whether the downloadable Telegram files open correctly and contain current instructions before relying on them. For the core setup, Telegram’s official Bot API documentation remains the authority for commands, webhook formats and message limits.
Next, create the destination chat. In a Telegram channel, add the bot as an administrator with permission to post messages; in a private group, grant the necessary permission and record the numeric chat identifier. Send a test message during setup because a valid token still cannot deliver to a chat the bot cannot access.
Finish by choosing a private webhook URL and a random secret token. The handler should compare Telegram’s X-Telegram-Bot-Api-Secret-Token header with the stored value before processing any request. This prevents unrelated callers from making your bot send arbitrary messages.
Connect the uptime monitoring service
Create an account with an uptime monitoring provider such as Better Stack, Better Uptime, StatusCake or Pingdom, using a service appropriate to your checks and budget. Give it a dedicated monitor for each critical endpoint, set the timeout and expected response, and retrieve its API key. Do not put that key in the same repository as the Telegram token.
For a small static site, a scheduled worker can query a monitoring API and send a message when its state changes. For important services, an external monitor should perform the checks and deliver a webhook to your handler, which then forwards a formatted status update to Telegram. The second approach also detects the failure of your own hosting platform.
Compare the delivery approaches before choosing one:
| Approach | How it works | What it reveals | Operational burden |
|---|---|---|---|
| Scheduled bot polling | A worker queries the monitoring API on a schedule | Reports status changes already detected by the provider | Low, but depends on scheduler and API limits |
| Hosted monitor with webhook | The provider checks the site and posts JSON to your handler | Detects public outages from outside your network | Medium, because the endpoint and secret require management |
| Self-hosted checker | Your worker performs the HTTP requests directly | Detects outages visible only from its own network | High, since you manage TLS, retries and monitoring |
| Combined monitoring | A hosted service checks the site while a worker handles Telegram delivery | Shows both availability and alert-delivery health | Medium, with two systems to maintain |
Use the hosted webhook approach for production reliability. Configure the provider to POST status changes to your handler, then register the same HTTPS address with Telegram:
curl -X POST "https://api.telegram.org/bot<TOKEN>/setWebhook" \
-d "url=https://your-app.example.com/webhooks/uptime" \
-d "secret_token=YOUR_RANDOM_SECRET"
The secret must match in both systems. The handler can verify the provider’s payload, format a message and call Telegram’s sendMessage method with the recorded chat identifier. If you prefer a scheduled worker, query the provider’s API at your chosen interval instead and send only when the stored status changes.
Adapt the bot for Australian operations
Australian teams span Australian Eastern Standard Time and Australian Eastern Daylight Time, Central Australian Standard Time and Central Australian Daylight Time, and Australian Western Standard Time. Daylight saving changes complicate quiet hours and maintenance windows, especially for teams coordinating Melbourne, Brisbane and Perth. Brisbane and Perth do not change their clocks, so store timestamps in UTC and calculate the next transition rather than applying a fixed offset.
Add vantage points that reflect your audience when availability differs by geography. A check from Sydney may succeed while Brisbane users experience a degraded route, or a CDN edge in Melbourne may mask an origin fault. Keep a primary external check and use regional probes as diagnostic evidence, not as extra alerts for every small latency change.
Domain lifecycle belongs in the same runbook. For an Australian .com.au or .au domain, track registration expiry, nameserver changes and certificate renewal alongside uptime. During a long incident, a quick how many days calculation can help reconcile outage timestamps with supplier statements, while your incident log remains the authoritative record. Retailers, service businesses and agencies should also monitor checkout or booking paths, since a reachable homepage does not guarantee a usable sale.
Diagnose SSL and delivery failures
SSL errors need precise wording because they differ from an HTTP outage. Cloudflare error 525 means Cloudflare could not establish a secure connection to the origin server, often because of an incompatible certificate, an incomplete certificate chain, a hostname mismatch or unsuitable TLS settings. Check the certificate on the origin directly, confirm modern TLS support and use Cloudflare’s Full (strict) mode where appropriate rather than Flexible mode.
Keep other status codes separate in the alert format. A 403 can indicate a bot block, a 429 can mean your check frequency exceeds a limit, and a cached 200 can hide a broken application. Distinguish these outcomes from a transport timeout so responders know whether to investigate configuration, rate limits, DNS or application health. The main Telegram resource page currently displays a Cloudflare 525 SSL handshake failure, so do not rely on it for incident instructions or treat its availability as evidence that your Telegram setup is working.
Webhook delivery introduces its own failure modes. Reject a request with the wrong secret, return a successful response quickly and queue any slow formatting work. Telegram retries webhook deliveries if it does not receive a timely response, so design the handler to avoid duplicate notifications. Store only the diagnostic fields your team needs. If logs contain customer identifiers or other personal information, check whether the Australian Privacy Act 1988 and Australian Privacy Principles apply to your organisation.
Put the bot into daily service
Test the complete chain before relying on it. Use a staging endpoint or a deliberately controlled failure to trigger a down notification, a recovery notification and an SSL or timeout error. Confirm that the message reaches the intended chat, contains the correct URL and status, and remains readable during an overnight alert in Sydney.
Assign ownership for the bot, the monitoring account and the destination channel. Keep a small runbook with escalation steps, test the renewal of certificates and API credentials, and set provider and Telegram usage limits where available. Remove test chats and revoke tokens that have been exposed, then record the final alert thresholds with the team.
Once those checks pass, publish the bot’s purpose in your team channel and document how to request a status check. A steady signal is more valuable than a noisy stream of reminders, so tune thresholds before expanding coverage. Create the BotFather bot today, connect one critical endpoint, and send a verified failure-and-recovery alert to your Australian team’s Telegram channel.