Schedule planned maintenance
When to use maintenance
Create a maintenance window when planned work may interrupt, slow, or change a monitored service. Examples include database upgrades, infrastructure moves, DNS changes, certificate work, and provider maintenance.
Do not use maintenance to hide an unexpected active incident. If customers are already affected by unplanned behavior, manage it as an incident.
Planned work stays separate from an outage
Scheduled work is shown neutrally and does not look like unexpected downtime.
Database maintenance
Sep 17 · 2:00–3:00 AM EDT
Dashboard and API
Create a maintenance window
Open Maintenance
Choose Maintenance from the dashboard navigation. Move to the correct month and select the intended date.
Add a clear title
Use customer-readable language such as Database maintenance or Network upgrade, not an internal ticket number alone.
Set the start and end
Choose the expected time range and verify the timezone. Include preparation or recovery time when the service may still behave differently.
Select affected monitors
Choose only the services that may be affected. This scope controls which monitoring and public status components recognize the window.
Describe the expected impact
Tell readers whether they should expect no impact, brief interruptions, degraded performance, or a temporarily unavailable feature.
Publish when customers should see it
Draft internal planning first if needed, then publish the window to matching status pages when the schedule is ready to communicate.
Choose the right scope
If work affects only exports, do not include sign-in, billing, and the public API. Accurate scope helps customers decide whether the maintenance matters to them.
When one internal monitor represents several public components, review the status-page mapping before publishing.
Understand monitor behavior
An active maintenance window provides context for failures from included monitors and prevents planned behavior from looking like an unexpected incident. The monitor’s historical evidence remains available.
Maintenance does not delete checks or erase past uptime data. It adds a neutral time range that explains why behavior changed.
What appears on charts
The monitor detail chart can show maintenance as a neutral overlay aligned with its exact start and end time. The Events row also lists the window and provides quick details on hover.
The overlay helps explain why performance changed during the period. The Events row gives a compact operational timeline. Both are intentional and should remain visually different from failed checks and incidents.
Write a helpful maintenance notice
A useful notice answers:
- What work is happening?
- When does it start and end?
- Which customer capabilities are affected?
- What impact should customers expect?
- Is any action required from them?
Example:
We will upgrade the reporting database on September 17 from 2:00–3:00 AM EDT. New report generation may pause briefly during this window; existing dashboards will remain available. No customer action is required.
During the window
Monitor the affected services and compare actual impact with the notice. If the work starts late, finishes early, or runs beyond the planned end, update the window.
If an unrelated or more severe failure occurs, do not assume maintenance explains it. Inspect the evidence and open an incident when the behavior is outside the planned scope.
Complete the maintenance
Before marking work complete:
- confirm every affected monitor is healthy;
- test the important customer action;
- check for queued or delayed work;
- update the public notice;
- record any follow-up work.
Keep the completed window in history. It provides valuable context when reviewing charts, incidents, and service changes later.