How to Configure Downtime Alerts (Uptime Monitor) in MU Online

The worst scenario for a MU Online administrator is not the server going down — it is the server going down and you finding out hours later, from an angry player's screenshot on Discord. Every minute offline without you knowing is reputation and retention evaporating. An uptime monitor solves exactly that: an automated watchdog that tests, from the outside, whether your server is accepting connections and, the instant something fails, notifies you via Discord, Telegram or email. This tutorial shows how to build that system by testing the right MU ports (not just whether the machine is on), avoiding false alarms and creating a status page for the community. The tools, plans and values mentioned are examples and vary by provider/version; the concept is what you will take away.

Prerequisites

• A MU server already published and reachable over the internet (if you are still building it, see how to create a MU Online server).
• The server's public IP or domain and the ports that players use.
• A second point to host the monitor: a separate cheap VPS, an external monitoring service, or even a Raspberry/PC running 24/7 — the key is that it be independent from the monitored machine.
• A ready alert channel: a Discord webhook, a Telegram bot or an SMTP email account.
• A list of the critical services to watch: ConnectServer, GameServer(s), database and website.

Step 1 — Know exactly what to monitor

Monitoring "the server" is vague. The player does not connect to a machine, they connect to service ports. And each downed service has a different effect. Mapping this is the first step.

The exact ports vary by version and configuration. As a common example on S6 servers, the ConnectServer usually responds on a well-known TCP port and each GameServer on another range. What matters is: find your real ports in the configuration files and monitor each one. A monitor that only checks whether the IP responds to ping cannot detect a frozen GameServer on a machine that is still on — and that is exactly the most frustrating case.

Step 2 — Choose where the monitor will run

The golden rule: monitor from the outside. If the monitor runs inside the game's own VPS and the whole machine goes down or loses network, the monitor goes down with it and never fires the alert. You have three approaches, from the simplest to the most complete:

1. External monitoring service: register the IP and port on a cloud platform that checks from several points around the world. Quick to set up; free plans are usually enough to start (varies by provider).
2. Open-source monitor on your own cheap VPS: you host the tool on a second machine, keeping full control and no license cost.
3. Your own script: a lightweight script that tests the port and fires a webhook — maximum flexibility, useful for MU-specific checks.

The mature ideal combines item 1 or 2 (main, external alert) with item 3 (internal process checks). Start simple and evolve.

Step 3 — Test the right port (not just the ping)

The heart of the monitor is the TCP port test. It confirms that the service accepts a connection, which is what the game client needs. A PowerShell script illustrates the concept and already serves as a homemade monitor on Windows:

# monitor-porta.ps1 — tests the ConnectServer port and alerts on Discord
$alvo    = "YOUR.SERVER.IP"
$porta   = 44405      # EXAMPLE: use your ConnectServer's real port
$webhook = "https://discord.com/api/webhooks/YOUR/WEBHOOK"

$ok = Test-NetConnection -ComputerName $alvo -Port $porta -InformationLevel Quiet

if (-not $ok) {
    $corpo = @{ content = "🔴 ALERT: $alvo:$porta is NOT responding at $(Get-Date -Format 'HH:mm:ss')" } | ConvertTo-Json
    Invoke-RestMethod -Uri $webhook -Method Post -Body $corpo -ContentType 'application/json'
}

On Linux, the same port test is trivial with nc (netcat):

# returns success if the port accepts a connection
nc -z -w 3 YOUR.SERVER.IP 44405 && echo "UP" || echo "DOWN"

For the website, the test is HTTP: beyond the port being open, the server must respond with a success code (200). A curl -sf https://yourdomain.com/ that fails is a sign the site is down even with port 80/443 open.

Step 4 — Avoid false alarms

A monitor that screams at every network fluctuation becomes noise, and noise we learn to ignore — then, when the outage is real, no one pays attention. Three techniques tame false positives:

• Confirmation by repetition: only alert after 2 or 3 consecutive failed checks. A single lost packet does not really take the server down.
• Sensible interval: checking every 30-60 seconds detects fast without overdoing the traffic. Extremely short intervals increase the noise.
• Maintenance window: when restarting the server on purpose, silence the alerts during that interval so you are not startled by your own maintenance.

An example of confirmation by repetition, incrementing a counter before alerting:

# only alerts on the 3rd consecutive failure
$falhas = 0
foreach ($tentativa in 1..3) {
    if (Test-NetConnection $alvo -Port $porta -InformationLevel Quiet) { $falhas = 0; break }
    $falhas++
    Start-Sleep -Seconds 5
}
if ($falhas -ge 3) { <# fire the alert here #> }

Step 5 — Configure the alert channels

An alert is only useful if it reaches you where you are looking. The three channels most used by MU servers:

Discord (webhook): the most popular, since the community already lives on Discord. Create a webhook in a private staff channel (Channel Settings → Integrations → Webhooks) and use the URL as in the script above. Simple and instant.

Telegram (bot): great for alerts on your phone. Create a bot with BotFather, grab the token and the chat id, and send the message:

curl -s "https://api.telegram.org/botYOUR_TOKEN/sendMessage" \
  -d chat_id=YOUR_CHAT_ID \
  -d text="🔴 GameServer down at $(date +%H:%M)"

Email (SMTP): good as a secondary/redundant channel. Use an app password from your email provider, never the account's main password.

The recommendation is to have at least two channels: if Discord happens to be having trouble right when the outage hits, Telegram or email ensures the notification still gets through.

Step 6 — Schedule the continuous check

The monitor needs to run on its own, forever. On Windows, schedule the script in Task Scheduler with a repeating trigger:

1. Open taskschd.msc and create a task.
2. Trigger: at system startup, repeating every 1 minute indefinitely.
3. Action: powershell.exe -NonInteractive -ExecutionPolicy Bypass -File "C:\Monitor\monitor-porta.ps1".
4. Check "Run whether the user is logged on or not".

On Linux, cron covers down to the minute interval; for more frequent checks, a systemd service in a loop with sleep is the standard. If you are using an open-source uptime tool, it already manages the scheduling internally — you just register the target, the port and the interval through the interface.

Step 7 — Status page for the community

Beyond alerting you, a good system informs the players. A public status page that shows "Online / Offline" for each service dramatically reduces the volume of questions in chat during an outage and conveys professionalism. Open-source monitoring tools already generate this page automatically; you choose what to expose:

• Status of each GameServer and of the ConnectServer.
• Uptime over the last 30/90 days as a percentage.
• Incident history with start and resolution times.

A community that sees "we are aware, service under maintenance" on the status page waits; a community with no information assumes abandonment and migrates. The status page is as much a part of monitoring as the alert itself.

Common errors and fixes

Launch checklist

• Real ConnectServer and GameServer ports identified in the config files
• Monitor testing the TCP port, not just ping
• Monitor running from an external point independent of the game VPS
• Website tested over HTTP (code 200), not just an open port
• Confirmation by repetition (2-3 failures) active against false positives
• Check interval between 30 and 60 seconds
• At least two alert channels configured (e.g. Discord + Telegram)
• Maintenance window to silence alerts during planned restarts
• Scheduled check running 24/7 automatically
• Public status page for the community

With a well-built uptime monitor, an outage stops being an embarrassing surprise and becomes an incident you are already resolving before the first player complains. By testing the right port, from the outside, with redundant alerts and no false alarms, you turn offline time into minutes of reaction — and it is that speed that separates an amateur server from a project the community trusts.

Frequently asked questions