How far ahead to publish?

24–72 hours for customer-facing work. Major migrations: a week or more.

What does incident suppression do?

Pauses automatic incident creation from monitors during the window. Monitoring stays on; only auto-incidents are suppressed.

Every deploy needs maintenance?

No. Use maintenance records for customer-visible or high-risk work. Silent backend deploys often skip public posts.

Preview or copy each section below. Paste into Notion, Confluence, or your wiki.

Maintenance plan

Maintenance: [Title]

Planned work with a clear customer story and rollback path.

Plan

Field	Value
Deduplication key	[stable-key]
Owner	[Name]
Window	[start] → [end] ([timezone])
Auto-start / auto-end	Yes / No · grace [X] min
Suppress auto-incidents	Yes / No: only if monitors would false-page
Status page	[Page name]

Summaries

Customers see: [Plain language, e.g. brief disconnects, read-only mode]

Team sees: [Deploy steps, blast radius, rollback owner]

Affected components

Component	Status during window	Notes
[API]	Degraded	Rolling restart
[Dashboard]	Operational	No impact

Comms timeline

When	Action
[X]h before	Advance notice + subscriber email
Start	“In progress” update
End	“Complete” update

Copy-paste messages

Advance: Scheduled maintenance on [component] from [start] to [end]. [Impact sentence.]

In progress: Maintenance on [component] is in progress. [Impact]. We will update when done.

Complete: Maintenance on [component] is complete. All systems operational.

Execution

Before

Approval / change ticket recorded
On-call aware
Rollback documented
Dashboards open

During

Post in-progress at actual start
Abort if: [metric/symptom] → rollback

After

Verify key journeys
Post complete + close maintenance
Log issues on incident timeline if needed

Rollback

[Steps · owner · time limit]

# Maintenance: [Title]

> Planned work with a clear customer story and rollback path.

## Plan
| Field | Value |
|-------|-------|
| Deduplication key | [stable-key] |
| Owner | [Name] |
| Window | [start] → [end] ([timezone]) |
| Auto-start / auto-end | Yes / No · grace [X] min |
| Suppress auto-incidents | Yes / No: only if monitors would false-page |
| Status page | [Page name] |

## Summaries
**Customers see:** [Plain language, e.g. brief disconnects, read-only mode]

**Team sees:** [Deploy steps, blast radius, rollback owner]

## Affected components
| Component | Status during window | Notes |
|-----------|---------------------|-------|
| [API] | Degraded | Rolling restart |
| [Dashboard] | Operational | No impact |

## Comms timeline
| When | Action |
|------|--------|
| [X]h before | Advance notice + subscriber email |
| Start | “In progress” update |
| End | “Complete” update |

### Copy-paste messages
**Advance:** Scheduled maintenance on [component] from [start] to [end]. [Impact sentence.]

**In progress:** Maintenance on [component] is in progress. [Impact]. We will update when done.

**Complete:** Maintenance on [component] is complete. All systems operational.

## Execution
**Before**
- [ ] Approval / change ticket recorded
- [ ] On-call aware
- [ ] Rollback documented
- [ ] Dashboards open

**During**
- [ ] Post in-progress at actual start
- [ ] Abort if: [metric/symptom] → rollback

**After**
- [ ] Verify key journeys
- [ ] Post complete + close maintenance
- [ ] Log issues on incident timeline if needed

## Rollback
[Steps · owner · time limit]

How to use this template

Create the record when the window is approved, not day-of.
Map components to your status page before scheduling.
Enable suppression only for expected monitor noise during the window.

Incido maintenance supports planned windows, auto-start/end, affected components, incident suppression, and status-page publishing with subscriber email.

Explore status page

Maintenance Window Planner