Maintenance Windows

Maintenance windows let you define time periods when you expect disruptions — deployments, database migrations, infrastructure upgrades. During a maintenance window, Ionhour can suppress alerts and/or incidents for the affected projects so your team isn't bombarded with notifications about expected downtime.

How Maintenance Windows Work

A maintenance window is a workspace-scoped time range that targets one or more projects. When the window is active:

• Suppress alerts — alert channels don't fire for checks in the targeted projects.
• Suppress incidents — incidents aren't created for checks in the targeted projects.
• Status page integration — optionally auto-publish the maintenance to your status page.

You control which suppression behaviors are active. You can suppress alerts only (incidents still get created for record-keeping), suppress both, or just use the window as a status page announcement.

Window Settings

Window Lifecycle

Every maintenance window follows this state machine:

SCHEDULED → ACTIVE → COMPLETED
                  ↘ CANCELLED

Target Projects

Each maintenance window targets one or more projects. Only checks within those projects are affected by the suppression settings. Checks in other projects continue to operate normally.

This project scoping lets you schedule maintenance for your payment service without silencing alerts for your marketing site.

Suppression Options

Suppress Alerts

When suppressAlerts is true (default), alert channels don't fire for checks in the targeted projects during the active window. Incidents may still be created (depending on suppressIncidents), but no notifications are sent.

This is useful when you want to maintain an incident record for audit purposes but don't want to wake anyone up.

Suppress Incidents

When suppressIncidents is true (default), incidents are not created for checks in the targeted projects during the active window. Since no incidents are created, no escalation policies are triggered.

Enable both suppression options for maximum quiet during maintenance.

Alert-Only Suppression

Set suppressAlerts: true and suppressIncidents: false if you want to:

• Keep a record of any issues that occurred during maintenance
• Review incidents post-maintenance to verify everything recovered
• But not notify anyone during the window

Recurring Maintenance Windows

For regularly scheduled maintenance (e.g., weekly patching, nightly batch jobs), set the recurringCron field with a cron expression. The window will automatically reschedule after each completion.

The cron expression follows standard cron syntax and is interpreted in the window's configured timezone.

Example: Weekly Tuesday Night Maintenance

Status Page Integration

When autoPublishToStatusPage is true, Ionhour automatically creates a maintenance announcement on your status page when the window becomes active. This keeps your customers informed about planned downtime without requiring manual status page updates.

The announcement is removed when the window completes or is cancelled.

Creating a Maintenance Window

Maintenance Windows vs. Deployments

Ionhour has two features for managing planned downtime:

Use maintenance windows for infrastructure-level planned downtime that affects multiple projects. Use deployments for individual application releases where you want to pause specific checks.

Interaction with Escalation Policies

During an active maintenance window:

• If suppressIncidents is true, no incidents are created, so no escalation fires.
• If suppressAlerts is true but suppressIncidents is false, incidents are created but escalation dispatches are suppressed for the targeted projects.

After the window ends (state becomes COMPLETED), normal alerting and incident creation resume immediately.

Best Practices

• Always set target projects. A maintenance window without targets doesn't suppress anything. Be explicit about which projects are affected.
• Use both suppression options for true maintenance. If you're doing a database migration, you probably want to suppress both alerts and incidents. Half-measures (suppressing alerts but not incidents) should be a deliberate choice, not the default.
• Schedule ahead of time. Create windows in SCHEDULED state well before the maintenance starts. This gives your team visibility into upcoming quiet periods.
• Enable status page auto-publish for customer-facing services. Your customers will appreciate knowing about planned downtime before it happens.
• Cancel, don't delete. If maintenance is called off, cancel the window rather than deleting it. The CANCELLED state preserves the history for audit purposes.
• Use recurring windows for regular maintenance. If you patch every Tuesday night, set up a recurring window instead of creating a new one each week.
• Review post-maintenance. After the window completes, check the incident list for any incidents that were suppressed. If something broke during maintenance and didn't auto-recover, you'll want to investigate.