How to create a Telegram bot that sends daily weather updates

A Telegram weather bot can turn a simple forecast lookup into a useful daily service. At a set time each morning, it can retrieve current conditions, prepare a concise message, and deliver it to subscribers in a private chat or group. The same system can also include rain probability, wind, humidity, UV levels and warnings.

For an Australian audience, the bot should be designed around local habits and conditions. People may want a forecast before commuting across Sydney, planning a beach morning in Perth, opening a café in Melbourne or sending workers to a job site near Brisbane. Using Celsius, Australian place names and data from a suitable weather provider makes the updates more practical.

Choose the weather data and Telegram tools

You need three main components: a Telegram bot account, a weather API and a small application that connects them. Create the bot through BotFather in Telegram, then save the token securely. Anyone with the token can control the bot, so it should never be published in source code or committed to a public repository.

For forecast information, choose an API that supports Australian locations and provides the fields your subscribers actually need. OpenWeatherMap, WeatherAPI and similar services commonly offer temperature, conditions, wind and precipitation data. The Bureau of Meteorology is an important reference for Australian forecasts and warnings, although its technical access options differ from commercial APIs.

Python is a convenient choice because libraries such as python-telegram-bot simplify message delivery. A lightweight Node.js application can achieve the same result with a Telegram framework and an HTTP client. Select the language you can maintain confidently rather than choosing a tool solely because it is popular.

Create the bot and collect locations

Open Telegram, search for BotFather and send /newbot. Telegram will ask for a display name and a username ending in bot. After creation, BotFather supplies an access token. Store it in an environment variable such as TELEGRAM_BOT_TOKEN, rather than placing it directly inside the program.

The first version can use commands such as /start, /weather, /setlocation and /stop. When someone starts the bot, explain what information will be sent and how often. Ask for a suburb, city or postcode, then convert that input into latitude and longitude using a geocoding service.

Avoid assuming that a suburb name is unique. “Richmond”, for example, can refer to places in different states. Ask the user to confirm the matched location, such as “Richmond, Victoria”, before saving it. This reduces inaccurate results and prevents a subscriber in Adelaide from receiving a forecast for a similarly named location elsewhere.

A simple stored record might contain the Telegram chat ID, latitude, longitude, display name, delivery time and time zone. SQLite works well for a small project, while PostgreSQL is more appropriate when the subscriber list grows. Store only information needed for the service and provide a clear way to delete a user’s details.

Format a useful daily forecast

A daily message should be brief enough to read quickly. A practical layout is:

Good morning from Melbourne

Today: 12–21°C
Conditions: Partly cloudy
Rain chance: 30%
Wind: W 18 km/h
UV: High

You can add sunrise and sunset times, apparent temperature and a short packing suggestion. “Bring a light jacket” may be useful on a cool Melbourne morning, while “Carry water and use sun protection” is more relevant during a hot Adelaide afternoon. Keep these statements based on actual forecast values rather than making dramatic predictions.

Use Australian spelling and units consistently. Temperatures should be shown in Celsius, wind should use kilometres per hour, and rainfall should use millimetres. A subscriber in Darwin may care more about storms and humidity, while someone in Hobart may value minimum temperatures and wind chill.

Health-related details require restraint. Heat and poor air quality can affect people differently, so the bot should present factual forecast information rather than personal medical advice. For general background that may help when designing heat-related notices, a health reference can be reviewed separately, but it should not replace advice from a qualified Australian health professional.

Write the forecast retrieval code

The program should first read the saved user locations, call the weather service for each location and transform the response into a message. A simplified Python structure might look like this:

import os
import requests

def get_forecast(lat, lon):
    params = {
        "lat": lat,
        "lon": lon,
        "appid": os.environ["WEATHER_API_KEY"],
        "units": "metric"
    }
    response = requests.get(
        "https://api.openweathermap.org/data/2.5/weather",
        params=params,
        timeout=10
    )
    response.raise_for_status()
    return response.json()

The production version should use a forecast endpoint rather than relying only on current conditions. Check whether the provider returns a daily forecast, hourly precipitation, UV information and severe-weather data. Validate every field before formatting it because APIs can omit values or change response structures.

Add error handling for timeouts, rate limits, invalid coordinates and expired credentials. If the weather service fails, do not send a message containing blank values. Log the problem, retry carefully and send a short service notice only when necessary. A failure in one location should not prevent updates for every other subscriber.

Round temperatures sensibly and avoid excessive decimal places. Convert wind direction from degrees into readable points such as north-west if that helps your audience. For a more polished experience, translate provider condition codes into stable labels instead of displaying raw API terminology.

Schedule messages for Australian time zones

Daily delivery requires a scheduler. You can run a task with Linux cron, use an asynchronous job queue or deploy a scheduled serverless function. The scheduler should trigger the application regularly, while the application decides which subscribers are due for an update.

Australian time zones need special care. Sydney, Melbourne, Canberra, Hobart and Brisbane use Eastern time, but Queensland does not observe daylight saving. Adelaide and Broken Hill use Central time, while Perth uses Western time. New South Wales, Victoria, Tasmania and the Australian Capital Territory change clocks seasonally, so storing a fixed UTC offset will eventually produce incorrect delivery times.

Use IANA time-zone names such as Australia/Sydney, Australia/Brisbane, Australia/Adelaide and Australia/Perth. Let users choose a preferred delivery time, then calculate the matching UTC time with a time-zone library. This is especially important around daylight-saving changes, when a message scheduled at 7:00 am should remain at 7:00 am local time.

A good default for a consumer bot is 7:00 am, although tradies, farmers and commuters may prefer an earlier update. Give users commands to change their time and location. If the service targets multiple states, test dates around daylight-saving transitions before launch.

Add Australian warnings and practical controls

A generic weather API may not provide complete emergency information. For Australia, consider linking users to official Bureau of Meteorology warnings or state emergency services when dangerous conditions are detected. The bot should clearly identify the source and time of the warning instead of presenting an unofficial interpretation as an emergency instruction.

You can create thresholds for heavy rain, extreme heat, strong wind or high UV. Keep them configurable because local conditions differ. A threshold suitable for a tropical Darwin audience may not make sense for Hobart. Treat thresholds as notification triggers, not medical or safety guarantees.

Give subscribers control over frequency and content. Commands such as /mute, /resume, /settings and /delete improve trust. A group administrator might want one forecast at 6:30 am, while individuals may prefer private alerts. Rate-limit commands and ignore unexpected input rather than allowing users to trigger unlimited API requests.

For ideas about how messaging projects organise features and categories, browse bot examples while planning the command structure. Use external examples for inspiration, then verify their permissions, privacy practices and technical assumptions before adapting anything.

Test, deploy and protect the service

Test the bot with locations in several states, including Sydney, Brisbane, Perth and Melbourne. Check hot and cold forecasts, missing rain data, unusually long suburb names and users who stop interacting. Confirm that Markdown or HTML formatting is escaped correctly so a location name cannot break the message layout.

Run a small private trial before inviting a larger audience. Measure API response times, failed deliveries, duplicate messages and users who receive updates at the wrong local hour. Telegram can reject messages when a user has blocked the bot, so handle those errors by disabling future sends for that chat.

For deployment, a small virtual server, container platform or managed application service is usually sufficient. Set environment variables for API keys, enable automatic restarts and keep logs free from tokens or unnecessary personal data. Restrict database access and apply software updates regularly.

A useful bot is built through gradual refinement. Start with one reliable morning forecast, then add severe-weather links, multiple saved locations, weekly summaries or subscriber preferences after the core workflow works consistently. Documentation about Telegram automation and related projects can be found through this Telegram resource, but always check current Telegram and weather-provider requirements before releasing code.

Build the first version with one location, one daily message and strong error handling. Once it delivers accurate forecasts at the correct Australian local time, invite a small group of testers, collect practical feedback and expand the features that genuinely help them plan their day.