How to monitor your MU Online server's uptime with multi-region checks

When a MU Online private server grows, "is the server down or is it just my internet?" becomes the most common support ticket on Discord. Monitoring uptime the naive way — a single ping script running on the same VPS as the game — doesn't solve this, because the script goes down along with the server and because it can't see regional routing issues. The professional solution is multi-region checking: several independent observation points, in different datacenters, checking the same target at the same time and comparing results. In this tutorial you'll learn what to monitor, how to set up this kind of checking with free and paid tools, how to configure alerts without causing notification fatigue, and how to communicate incidents transparently to the community.

Why local uptime checks aren't reliable

A monitor installed on the same machine or datacenter as the game server has two serious problems. First, if the entire VPS goes down (kernel panic, power failure, provider outage), the monitor goes down with it and can't even log the incident itself — you end up with no history exactly when you need it most. Second, it can't detect external connectivity issues: if your hosting provider has poor peering with specific Brazilian carriers, players on Vivo might be experiencing constant timeouts while the server "looks fine" according to any internal check.

Multi-region checking solves this by running probes from the outside in, from geographically distributed points, simulating the real connection experience of different audiences. It also separates two types of incidents that require different responses: a total service outage versus route degradation affecting a specific region.

What to monitor on a MU Online server

A MU server has multiple services that can fail independently. Monitoring them separately is essential for fast diagnosis:

Each row in this table should have its own monitor with its own history — lumping everything into a single "is the server online" check hides which part actually failed.

Choosing the checkpoints (regions)

For a mostly Brazilian audience, an efficient probe distribution looks like this:

Services like UptimeRobot, Better Uptime, Freshping, and Pingdom already offer probes in many of these regions, ready to use without building your own infrastructure.

Setting up checks with free tools

If your budget is tight, you can build a working multi-region check by combining free services:

• UptimeRobot (free plan): up to 50 monitors, checks every 5 minutes, multiple regions on paid plans, but the free tier already covers basic HTTP/TCP from a fixed point.
• Freshping: up to 50 free monitors with probes across several regions, including South America.
• Your own script on distributed VPS instances: if you already have contacts or acquaintances with VPS in different regions, a simple cron job does the job.

Example TCP check script for the GameServer port, run via cron every minute at each checkpoint:

#!/bin/bash
HOST="seuservidor.com.br"
PORT=55901
TIMEOUT=5
WEBHOOK="https://discord.com/api/webhooks/SEU_WEBHOOK_AQUI"

if timeout $TIMEOUT bash -c "cat < /dev/null > /dev/tcp/$HOST/$PORT" 2>/dev/null; then
  echo "$(date) OK - GameServer respondendo"
else
  echo "$(date) FALHA - GameServer sem resposta em $HOST:$PORT"
  curl -s -H "Content-Type: application/json" \
    -d "{\"content\": \"🔴 ALERTA: GameServer sem resposta em $(hostname) - $(date)\"}" \
    "$WEBHOOK"
fi

Configuring alerts without notification fatigue

Alerting on every micro network blip has the opposite of the intended effect: the team starts ignoring the warnings. Practical rules to avoid this:

• Require outage confirmation from at least 2 different checkpoints before firing a critical alert — this filters out routing issues isolated to a single probe.
• Use a retry interval of 30-60 seconds before treating the outage as real, absorbing momentary instability.
• Split channels: total outage alerts go to an emergency channel (SMS, phone call, push); latency degradation alerts go to a monitoring channel (Discord, email).
• Configure auto-resolution: when the service comes back, the system should notify automatically, without manual intervention.

Latency and the "up but bad" problem

A GameServer that responds to the TCP handshake but takes 2-3 seconds to process each packet is, in practice, unusable — yet it shows up as "online" on any binary monitor. To catch this, track response time on every check and set separate alert thresholds:

Log this history on a time-series chart — tools like Better Uptime and Grafana with Prometheus let you visualize latency spikes correlated with peak player hours, which helps plan infrastructure upgrades.

Public status page for the community

Beyond internal monitoring, publishing a public status page (status.seudominio.com.br) drastically reduces the volume of "is the server down?" tickets during incidents. Tools like Better Uptime, Instatus, and Statuspage generate this page automatically from the same monitors, showing:

• Current status of each service (site, GameServer, shop).
• Uptime history for the last 90 days.
• Timeline of past incidents, with cause and resolution.
• Email/RSS subscription for players who want to be notified automatically.

This also signals operational maturity to new players deciding whether it's worth investing time (and money in the shop) in your server.

Integrating alerts with Discord and Telegram

Most of the MU Online community lives on Discord, so alerts should land there first. Set up a dedicated webhook (not the general chat channel) for infrastructure alerts, with two visually distinct severity levels (red for total outage, yellow for degradation). Example payload:

{
  "embeds": [
    {
      "title": "🔴 GameServer fora do ar",
      "description": "Detectado por 3/5 regiões nos últimos 2 minutos.",
      "color": 15158332,
      "fields": [
        { "name": "Região", "value": "São Paulo, Miami, Frankfurt" },
        { "name": "Início", "value": "31/07/2026 21:14 BRT" }
      ]
    }
  ]
}

Having this alert automated, even before any player complains, lets you proactively announce on Discord that the team is already aware — which greatly reduces community anxiety during incidents.

Runbook: what to do when the alert fires

Having monitoring without a response process is only half the job. Define a simple, documented runbook:

1. Manually confirm the outage (open the launcher, try to log in).
2. Check GameServer and database logs from the last 5 minutes.
3. Check CPU/RAM/disk usage on the VPS — many MU outages come from memory exhaustion during events with many players online.
4. Restart the specific affected service (not the whole server, if possible).
5. Post an update on the status page and Discord, even if still under investigation.
6. Once resolved, write a short post-mortem: root cause and what will be done to prevent recurrence.

Common errors and fixes

Monitoring checklist

• Separate monitors for site, ConnectServer, GameServer, database, and shop.
• At least 3 checkpoint regions configured (Brazil, US, Europe).
• Alerts requiring multi-region confirmation before firing.
• Latency thresholds defined, in addition to binary up/down.
• Infrastructure alert webhook separate from the general chat.
• Public status page published and shared on Discord.
• Incident response runbook documented and tested.

With multi-region monitoring live, the next step is to review the infrastructure being observed itself — undersized servers keep going down no matter how fast you detect the problem. It's worth revisiting the server setup tutorial to make sure your VPS and network sizing matches the actual size of your player base.

Frequently asked questions