Uptime
Scheduled maintenance
Scheduled maintenance is planned work on a service that you announced beforehand, such as upgrades, migrations, or restarts.
How it is measured
Record notice given (for example 72 hours), planned and actual duration, affected components, and whether it counted against the SLO. Monitors should be tagged, not turned off.
Compare impact to forecast: users affected, errors seen, rollback needed. The gap between what you said and what happened is the quality metric.
Worked example
A podcast hosting company posts on March 4 that on March 8 at 04:00 UTC it will migrate the RSS feed database, and feed requests may fail for up to 20 minutes. Notice is 96 hours, by status page and email. The migration runs 04:00 to 04:17 with 6 percent of feed fetches failing.
Podcast apps retry, so listeners barely notice. The SLA excludes announced work up to 4 hours per month, so none of the 17 minutes counts.
How it differs
Scheduled maintenance is the work with prior notice. Maintenance window is the time slot reserved for it. The window is the container. The maintenance is what happens inside it.
Common errors
Giving no notice. Overrunning the slot silently. Scheduling during a launch. Forgetting third-party partners and webhooks. Not posting completion. Using maintenance to cover unplanned work.
In practice
Use a template for the notice: what, when, expected impact, and how to follow. Send it at least 72 hours before. Post updates when you start, if the work runs long, and when it is done.