Maintenance or outage?

Not all downtime is failure. A meaningful proportion of the moments when a service is unreachable are entirely deliberate: The operators took it offline, on purpose, at a time they chose, and told people in advance. The difficulty is that from outside the door looks the same either way.

Telling them apart takes about a minute and changes what you should do, because planned downtime has something unplanned downtime never has - A published end time.

The tells

A maintenance page, not an error

The clearest signal. A service taken down deliberately usually serves a branded page that says so, often with a return time. An unplanned failure produces an error: A 502, a 504, a connection timeout, or a default web server page nobody designed.

There is a middle case that confuses people: A bare 503 Service Unavailable with a Retry-After header. That is the correct, standards-compliant way to say "deliberately unavailable, come back in N seconds", and it is used for both maintenance and load shedding.

The clock

Maintenance windows cluster in the small hours of the provider's home timezone, on the quietest day of their week. For a US consumer service that usually means the early hours of Sunday morning Eastern time. For a game with a global player base it is often mid-morning UTC, chosen to be the least bad compromise across regions.

If a service becomes unreachable at 03:10 on a Sunday, maintenance is a much better first hypothesis than failure. If it happens at 14:00 on a Tuesday, it is not.

The pattern

Planned downtime repeats. If a service goes offline at the same time every Tuesday, or for five hours every six weeks, that is a schedule rather than a coincidence - And it means you can simply look it up.

Genshin Impact is the clearest example of the category: Every version update takes the game offline for roughly five hours on a predictable six-week cadence, announced in advance and compensated with in-game currency. A large share of "is Genshin down" searches are answered entirely by the patch calendar. Fortnite does the same thing at season transitions, and PlayStation Network announces its maintenance windows on its status page days ahead.

Everything else still works

Maintenance is usually scoped. A bank might take transfers offline while card authorisation continues; a game might close the store while matches carry on. Unplanned failures are messier and rarely respect subsystem boundaries that neatly.

Queues are not outages

A login queue is deliberate. When a service expects more simultaneous arrivals than it can admit at once - A season launch, a ticket sale, a market open - It admits people in a controlled stream rather than letting the whole crowd in and collapsing.

This is good engineering and it is frequently reported as an outage. The distinction is visible: A queue tells you your position and moves. A failure does not. If you are looking at a number that is going down, the system is working exactly as intended and you are in a line.

The same applies to a waiting room in front of a retail site during a launch, and to the "unusual traffic" interstitials that appear when a shared IP address has been rate limited.

Where to find the schedule

• The status page. Most publish planned maintenance ahead of time in a separate section from incidents. It is frequently the least-read part of the page.
• In-app announcements. Games and financial apps usually post maintenance notices in the client days ahead.
• The support social account. Often carries the reminder on the day.
• Business tenant dashboards. For enterprise software, tenant-specific maintenance appears in the admin console and never on the public page - Which is why your organisation can be affected while everyone else is fine.

Why services still need downtime

A fair question, given how much of the industry now deploys continuously without users noticing. Three things still genuinely require taking the service away.

Schema changes that cannot run online. Some database migrations need exclusive access to a table. On a large table that is minutes to hours, and during it nothing can write.

Coordinated state changes. Games in particular need every client on the same version at the same instant. You cannot have half a player base on the new patch and half on the old one when they share a match.

Infrastructure work with a real risk of failure. Moving a data centre, switching a primary database, replacing a core network device. Doing it in a declared window with staff standing by is considerably safer than doing it live and hoping.

Wikimedia does this transparently: A planned data centre switchover roughly once a year puts the site into read-only mode for a scheduled window. Everyone can still read; nobody can edit; the announcement goes out well in advance. That is what good planned downtime looks like.

What to do during maintenance

Note the stated end time, add a margin, and come back. Maintenance overruns - That is normal and is why the announced time is usually conservative.

Do not reinstall anything, do not clear anything, and do not reconfigure your network. It will come back on its own, and the only thing you can achieve in the meantime is breaking something that was working.

If maintenance runs materially past its window with no update, that is worth paying attention to: An overrun that is not being communicated sometimes means the maintenance itself went wrong, which turns a planned window into exactly the kind of outage that lasts a long time.