Uptime is a measurement of the infrastructure, not of your particular server. That distinction explains most of the confusion around it, and it works in both directions — a perfect uptime figure does not mean nobody had a bad evening, and a bad evening does not mean the figure is wrong.
What counts as what
| Event | Infrastructure downtime? |
|---|---|
| The node is unreachable | Yes. This is what uptime measures. |
| Your server crashed from a plugin | No. The infrastructure was running; your service stopped. |
| You stopped it to change a config | No. |
| Your server ran out of memory | No. That is a sizing or a leak question. |
| Your TPS dropped to 8 | No. It was up. It was slow, which is a different problem. |
| A player's own connection failed | No, and it is genuinely common. |
Why the distinction is not a technicality
«Up» and «working well» are different measurements and both matter. A server at 4 TPS is technically up and practically unplayable — and that is a performance question with its own articles, not a claim about infrastructure. Conversely, a node outage affects every service on it at once, which is why it is measured separately and reported publicly.
Working out which one you had
- Check the status page for the time it happened
It shows what the infrastructure was doing. If the node was fine, the answer is in your own console.
- Read your console around that timestamp
A crash, an out-of-memory error, or a scheduled restart all leave a record. Silence during an outage is different from a stack trace.
- Ask whether it was everybody
A whole-node problem affects everyone at once. One player disconnecting while others play is a connection question, not an outage.
The status page says what the infrastructure did; your console says what your service did. Almost every «was that you or me?» question is answered by reading both for the same five minutes.
If you think you are owed compensation
The service level agreement sets out what qualifies and how to claim, and there is a separate article on the process. The short version is that it goes through a ticket on the billing portal with the dates and times, which the published uptime record is then checked against.