How to set up incident alerts via Telegram for your MU Online server

When the GameServer goes down at 3 AM and nobody notices until players start complaining on Discord, the cost isn't just technical — it's reputational, and on monetized servers, financial too (donations and paid events interrupted without warning). A Telegram-based alert system solves this blind spot, notifying the admin team within seconds, directly on their phone, without relying on someone watching a dashboard. This tutorial shows how to create the bot, write verification scripts for your MU Online server's critical services, configure escalation, and test failures in a controlled way before trusting the system in production.

Why Telegram instead of email or SMS

Email has variable delivery delay and frequently ends up in spam when sent by an automated script without reputable SMTP infrastructure. SMS has a per-message cost and doesn't scale well for frequent alerts. Telegram, on the other hand, offers a free bot API, near-instant delivery via push notification on the phone, and supports groups with multiple admins receiving the same alert simultaneously — it's the most widely used channel today by private server admins precisely because of this combination of zero cost and speed.

Creating the bot on Telegram

1. Open a conversation with @BotFather on Telegram.
2. Send /newbot and follow the instructions, setting a name (e.g., "ViciadosMU Monitor") and a username ending in "bot" (e.g., viciadosmu_monitor_bot).
3. BotFather returns a token in the format 123456789:ABCdefGhIJKlmNoPQRsTUvwxYZ — guard it with the same care as a database password.
4. Create a Telegram group with the admins and add the bot to that group.
5. Find the group's chat_id by accessing https://api.telegram.org/bot<TOKEN>/getUpdates after sending any message in the group — the group's chat_id appears in the returned JSON (usually a negative number).

Monitoring structure: what to check on the MU server

Verification script in Bash (Linux)

A simple script, run via cron every minute, covers most cases:

#!/bin/bash
# monitor_mu.sh
TOKEN="123456789:ABCdefGhIJKlmNoPQRsTUvwxYZ"
CHAT_ID="-1001234567890"
STATE_FILE="/tmp/mu_monitor_state"

send_alert() {
    local message="$1"
    curl -s -X POST "https://api.telegram.org/bot${TOKEN}/sendMessage" \
        -d chat_id="${CHAT_ID}" \
        -d text="${message}" \
        -d parse_mode="Markdown" > /dev/null
}

check_process() {
    local name="$1"
    local proc="$2"
    if ! pgrep -f "${proc}" > /dev/null; then
        if ! grep -q "${name}_DOWN" "${STATE_FILE}" 2>/dev/null; then
            send_alert "🔴 *ALERT*: ${name} went down on the server!"
            echo "${name}_DOWN" >> "${STATE_FILE}"
        fi
    else
        if grep -q "${name}_DOWN" "${STATE_FILE}" 2>/dev/null; then
            send_alert "🟢 *RECOVERED*: ${name} is back to normal."
            sed -i "/${name}_DOWN/d" "${STATE_FILE}"
        fi
    fi
}

check_process "GameServer" "GameServer"
check_process "ConnectServer" "ConnectServer"
check_process "MySQL" "mysqld"

Save it as /opt/scripts/monitor_mu.sh, give it execute permission (chmod +x), and schedule it in cron:

* * * * * /opt/scripts/monitor_mu.sh

Monitoring the site and panel

To check HTTP availability, add an equivalent function using curl with status code verification:

check_http() {
    local name="$1"
    local url="$2"
    local status
    status=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "${url}")
    if [ "${status}" != "200" ]; then
        send_alert "🔴 *ALERT*: ${name} responded with status ${status} (expected 200)."
    fi
}

check_http "Main site" "https://www.viciadosmu.com.br"
check_http "Login panel" "https://www.viciadosmu.com.br/login"

Avoiding alert fatigue with cooldown

Sending an alert every minute while the service is down makes the channel useless quickly — the team ends up muting the notifications. The pattern used in the script above (the STATE_FILE state file) solves this: the alert is only resent when the state changes (from "up" to "down" or vice versa), not on every cron run. For cases that require periodic reminders during long incidents, add a second timestamp that fires a "reminder" every 30 minutes while the service remains down.

Escalation by severity

Not every alert has the same urgency. Separate them by severity level so you don't mix a "disk 85% full" alert with "GameServer went down":

Create separate Telegram groups or topics per level, so critical alerts don't get lost among routine informational messages.

Testing the system before trusting it

Never trust an alert system that has never fired on purpose. Run a controlled test: manually stop the GameServer during a low-traffic time (systemctl stop gameserver or kill the process), confirm the alert arrives on Telegram in under 1 minute, bring the service back up, and confirm the "recovered" alert also fires. Repeat the test for MySQL and for the site, simulating each one going down in isolation.

Integrating with emulator-specific logs

Beyond processes and ports, many emulators generate log files with specific errors (mass authentication failure, account database connection error, unhandled exceptions). A tail -F combined with grep in a loop can trigger alerts when known error patterns appear:

tail -F /home/mu/GameServer/Log/error.log | while read -r line; do
    if echo "${line}" | grep -qi "database connection failed"; then
        send_alert "⚠️ GameServer log reported a database connection failure."
    fi
done

Run this loop as a separate systemd service, not inside the main cron, since it runs continuously.

Bot security best practices

Never leave the bot token in a public repository or in a script accessible via the site's URL. Treat it like a credential: store it in an environment variable or in a file with restricted permissions (chmod 600). If the token leaks, revoke it immediately via BotFather (/revoke) and generate a new one, updating every script that uses it.

Common errors and fixes

Alert deployment checklist

• Bot created with BotFather and token stored securely.
• Telegram group created with the admins and chat_id identified.
• Process verification script (GameServer, ConnectServer, MySQL) scheduled in cron.
• HTTP verification of the site and panel configured.
• Cooldown/state implemented to avoid alert fatigue.
• Severity levels defined and separated by channel/topic.
• Controlled outage and recovery test performed for each service.
• Monitoring of the monitor itself (watchdog) configured.

With alerts running reliably, the next step is to connect this monitoring to the overall server operation routine described in the tutorial on how to create a MU Online server, ensuring infrastructure, gameplay, and community are all covered by the same incident response process.

Frequently asked questions