Planned Maintenance and Uptime: What Should Count as Downtime?

Your report says the site was down for two hours this month. Those two hours were a planned database upgrade at 2 a.m. on a Friday, announced a week earlier. Was that downtime? The honest answer is "for your users, yes - for your SLA, it depends on what you promised". This guide explains how to keep both views straight.

Key takeaways

• Users experience planned and unplanned downtime the same way; your reports should show both.
• SLAs usually exclude announced maintenance - but only if the contract says so.
• Schedule maintenance windows in your monitoring tool so planned work doesn't page anyone.
• Announce maintenance in advance on a status page and keep windows short and predictable.
• Watch closely when the window ends: many incidents start right after maintenance.

Two different questions

There are two numbers worth tracking:

• Availability as users saw it - every minute the service didn't work, for any reason.
• Availability against the SLA - the same, minus the exclusions your agreement allows, typically announced maintenance.

Mixing them causes trouble in both directions. Report only the SLA figure and your team loses sight of how often users are locked out. Report only the raw figure and you may look worse than your contract requires.

What usually doesn't count against an SLA

Common contract exclusions are:

1. Maintenance announced a set time in advance (for example 48 hours or 7 days).
2. Maintenance inside an agreed window (for example Friday 01:00-05:00).
3. Outages caused by the customer or by force majeure.

Maintenance that runs past its window usually does count from the moment the window ends. So does "emergency maintenance" announced ten minutes before - read your own SLA before relying on it.

Setting up maintenance windows

In noc724, a maintenance window pauses alerts for the chosen monitors during the planned time:

1. Choose the monitors the work affects - not "everything".
2. Set the start and end time, with a little margin.
3. Decide whether the window is one-off or repeats (for example every Friday night).

Checks keep running during the window, so the history still shows what happened, but nobody gets paged for the downtime you planned.

Tell users before you start

Planned downtime feels very different when people know about it:

• Post the maintenance on your status page several days ahead, with start time, expected duration and what is affected.
• Use the users' time zone, or say which one you mean.
• Update the notice when work starts, if it overruns, and when it's finished.

A short, accurate notice prevents most of the "is it down?" messages that usually follow an outage.

Keep windows short and predictable

• Pick the hours with the least traffic for your audience - check your analytics instead of guessing.
• Prefer several small windows to one long one.
• Use rolling or blue-green deployments where you can, so routine releases need no window at all.

Watch the end of the window

Restarts, migrations and configuration changes are exactly when things break. When the window closes:

• confirm every affected monitor is back to "up",
• look at response times - a slow first hour often means cold caches or a missing index,
• keep someone on hand for the first 30 minutes.

Frequently asked questions

• Does planned maintenance lower my uptime percentage?

  +

  In the raw availability figure, yes. In an SLA calculation it usually doesn't, if the maintenance was announced and stayed within the agreed window.

• Should monitoring be switched off during maintenance?

  +

  No - pause alerts, not checks. Keeping checks running records exactly when the service went down and came back, which you need for reports.

• How far in advance should I announce maintenance?

  +

  Follow your SLA. Without one, a few days for routine work and at least a week for long or risky changes is a reasonable courtesy.