Your server goes down at 7pm. Within four minutes you have eleven messages in Discord asking whether it's down, two people saying "it works for me", and someone confidently blaming their ISP. You know less than you did before, and now you're doing support instead of fixing the server.
A status page changes the shape of that. One link, posted once, answers the question permanently, and keeps answering it while you're busy.
What a status page is actually for ¶
Not announcements, you have Discord for that. A status page does three specific jobs:
- Answers "is it just me". The single most common question during an outage, and the one you can automate away entirely.
- Separates you from the hosting provider. If your host has a network incident, a page showing the server unreachable from outside is evidence, not an accusation. Useful when you open a ticket.
- Keeps a record. "How often does this actually happen?" is unanswerable from memory and obvious from a history. It's also what you show a host when you're deciding whether to stay.
What to put on it ¶
For a Minecraft network, the useful set is smaller than people expect:
- The join address your players actually use. Not the backend node, the thing in your Discord channel topic. That's the thing that has to work.
- Your website or shop, if you have one. These fail independently of the server and generate their own support load, especially when someone's purchase doesn't go through.
- Any service you depend on that your players will blame you for. If your auth or your shop runs through a third party, its outage is your outage as far as your community is concerned.
What not to put on it: every backend node individually. Your players don't know what lobby-2 is and don't want to. Status pages fail by being too detailed far more often than by being too sparse.
Setting one up here ¶
If you're already monitoring the server, the page is a toggle rather than a project:
- Add a monitor for your join address, type Minecraft. We ping it with the Server List Ping, the same protocol the launcher and every server list use, and record status, latency, and player count.
- Turn on status-page visibility for the monitors you want public. Anything you don't tick stays private.
- Pick a slug. You get a public URL at
/s/your-slugto post in your Discord channel topic, your server-list description, and your rules channel.
The page shows current state, recent history, and past incidents, generated from the same checks that drive your alerts. There's nothing to update by hand, which matters, because a status page that relies on you remembering to update it during an outage is a status page that will be wrong exactly when it counts.
Pair it with alerts, not instead of them ¶
The page answers your players. Alerts tell you. Those are different jobs and you want both: a Discord webhook into a staff-only channel means you find out from the monitor rather than from a player, which is usually several minutes earlier and considerably less embarrassing.
One caution worth stating plainly: if your alerts route into the same Discord your players use, and your outage is Discord's, you get nothing. That's an argument for a second channel, email or a webhook, not for abandoning Discord alerts. We wrote about the general shape of this in is Discord down.
What it changes ¶
The realistic outcome isn't fewer outages, it's fewer conversations about them, and better ones when they happen. "Is the server down" stops being a question. "It's been down twice this week, both times at 7pm" becomes something you can say with evidence instead of a feeling, which is what actually gets a hosting problem taken seriously.
Status pages are part of the Pro plan. The monitoring and alerting underneath them work on the free plan, so you can have the server checked and alerting before deciding whether the public page is worth it to you.
FAQ ¶
Can I use my own domain?
Not currently, pages live under isitdown.io/s/your-slug. If a custom domain is a blocker for you, say so; it's a common request and knowing that helps us prioritise honestly rather than guessing.
Will it show my backend server addresses?
Only what you choose to make visible. Monitors default to private, and you tick the ones you want on the page.
What if the monitoring itself is down?
Then the page shows stale data, and that's a real limitation of every status page including ours. It's also why the page timestamps every reading, so "last checked 4 minutes ago" is visible rather than implied.