Uptime and maintenance windows explained
"99.9 percent uptime" sounds almost perfect, until you work out what it allows. Understanding uptime figures, and planning maintenance around the people who use your server, helps you set honest expectations, pick sensible restart times and judge any hosting claim you read. This guide explains the numbers and shows how to plan downtime that nobody notices.
What uptime means
Uptime is the share of time a service is available and working. It is usually shown as a percentage over a month or a year. The reverse, downtime, is what you actually feel.
| Uptime | Downtime per month (30 days) | Downtime per year |
|---|---|---|
| 99% | about 7 hours 18 minutes | about 3.7 days |
| 99.5% | about 3 hours 39 minutes | about 1.8 days |
| 99.9% | about 43 minutes | about 8 hours 46 minutes |
| 99.99% | about 4 minutes 22 seconds | about 52 minutes |
Each extra nine is dramatically harder and more expensive to deliver. A small community server does not need four nines, but a shop that earns money every minute might.
What the number does not tell you
- What counts as downtime. Some figures exclude planned maintenance, so a "99.9%" claim may ignore hours of scheduled work.
- Partial outages. A service that responds but is badly slow may count as up while feeling broken.
- Your own causes. A crash from a plugin, a full disk or a bad configuration is not the host's downtime, but your players still see it as yours. Many outages come from the application itself, not the machine.
- The measuring point. Checking from one location can miss regional problems.
Treat uptime guarantees as one input, not a promise of a perfect experience. For your own services, measure what users see.
Planned and unplanned downtime
Unplanned downtime is a crash, a failed disk, an attack or a mistake. You cannot schedule it, but you can reduce its chance and impact with backups, monitoring and sensible limits. See The 3-2-1 backup rule and DDoS attacks explained.
Planned downtime is work you choose to do: updates, restarts, migrations and cleanups. Because you choose the time, you can make it nearly painless.
Choosing a maintenance window
A maintenance window is a regular time reserved for work that might interrupt service. To choose one:
- Find your quiet hours. Look at when players or visitors are fewest. Many communities are quietest in the early morning in their main time zone.
- Consider where your users live. A community spread over several time zones has no perfect hour, so pick the least bad one.
- Keep it short and predictable. A fixed weekly slot is easier for people to plan around than surprises.
- Announce it. A pinned message or message of the day, such as changing your server MOTD, reduces complaints dramatically.
Time zones cause confusion. State the time clearly, ideally in more than one zone, and use a format such as "04:00 IST (22:30 UTC the day before)".
Automating restarts
Many game servers benefit from a regular restart to clear memory use. Doing it automatically at the quiet hour is better than doing it by hand. Warn players a few minutes ahead, and save the world first. Schedule automatic restarts and backups shows how to set this up in the panel, and on a VPS you can use cron or a systemd timer.
Before you do maintenance
A short checklist avoids most problems:
- Take a fresh backup, and know how to restore it.
- Read the update notes, looking for breaking changes.
- Do the change on a test copy first if the service matters.
- Have a rollback plan: the previous version, the old config, the backup.
- Schedule it when you have time to deal with surprises, not just before bed.
During maintenance
- Change one thing at a time, so you know what caused any problem.
- Watch the logs as the service starts. See How to read your server logs.
- Test from outside, as a user would, not only from the server.
- Keep a note of what you did.
After maintenance
Confirm everything started, check key features, and keep an eye on the service for the next few hours, since some problems only appear under load. Tell your users when you are done.
Updates that need restarts
Operating system updates sometimes require a reboot, especially kernel updates. You can apply many updates automatically, but plan the reboot. See How to turn on automatic security updates on Ubuntu. Make sure everything starts again by itself at boot, using systemd services or your panel's auto-start settings.
Keeping an honest record
Keep a simple log of outages: when, how long, the cause and the fix. Over time it shows patterns, such as a plugin that crashes weekly or a disk that keeps filling, so you can fix root causes instead of repeating the same incident. How to monitor your VPS with a few basic command line tools shows how to watch the signs.
Communicating during an outage
If something breaks, say so promptly. A short, honest note ("we are aware, investigating, next update in 30 minutes") earns more goodwill than silence. Avoid guessing at causes in public, and follow up when it is resolved.
Summary
Uptime numbers describe how much downtime you can expect, planned work can be moved to quiet hours, and good communication turns an outage into a minor event. If you need help during a problem, write a clear support request.
Still stuck? Open a ticket on Discord - run /ticket in any channel, pick a department, and include your Server ID or Invoice ID so we can jump straight in.