Maintenance windows
Plan work that would otherwise look like an outage.
A maintenance window is a period when checks keep running and results keep being recorded, but nothing alerts and no incident opens.
Why not just pause
Pausing stops checking, so you learn nothing about what happened. A maintenance window keeps the record: you can see afterwards exactly when the service went away and came back, which is what you want when the deploy did not go to plan.
It also starts and stops on its own, which matters more than it sounds — the most common monitoring failure of all is a monitor that was paused for a release in April and never turned back on.
What to enter
| Field | Notes |
|---|---|
| Name | So you can tell them apart. |
| Monitors | Which ones are covered. |
| Start and end | When it runs. |
| Timezone | So "2am" means your 2am, through daylight-saving changes. |
| Repeat | Don't repeat, daily, weekly, or monthly. |
Recurring windows suit a nightly batch that makes a service briefly unavailable, or a weekly reboot.
What happens during one
- Checks run as normal.
- Results are recorded and shown amber on the monitor's page.
- No incidents open and no alerts go out.
- Those checks are excluded from uptime, so planned work does not dent the figure.
- Check now is refused.
What it does not do
- It does not stop an incident that was already open. A window beginning during a real outage does not close it.
- It does not hide anything from your status page retrospectively.
- It covers the monitors you attached, not the whole account.
A practical pattern
Create a recurring window for known routine work — the nightly restart, the weekly index rebuild — and a one-off window for each planned release, scheduled a little wider than you expect to need. A window that ends ten minutes early turns the tail of your deploy into a page.
Last updated 4 October 2026
Still stuck?
If this did not answer your question, tell us and we will fix the page as well as answer you.