What's New

March 2026

Escalation Policies

Escalation policies replace the legacy per-project escalation rules with a more powerful, workspace-scoped system.

• Multi-target steps — each step can notify alert channels, specific users, teams, or on-call schedules simultaneously
• Priority-based matching — policies are evaluated in priority order; the first match wins
• Ack timeout — re-escalate if an acknowledged incident isn't resolved within a configurable window
• Repeat cycles — repeat the full escalation chain for long-running incidents
• Project filtering — scope policies to specific projects or use catch-all policies for everything else

Read the full documentation | API Reference

On-Call Schedules

Define who is responsible for responding to incidents with automated rotation management.

• Rotation types — daily, weekly, or custom (N-hour shifts)
• Multi-layer scheduling — higher-priority rotations override lower ones
• Overrides — temporary coverage swaps for vacations and shift trades
• Handoff notifications — notify the incoming on-call person before their shift starts
• Timezone support — handoff times are interpreted in the schedule's configured timezone

Read the full documentation | API Reference

Teams

Organize workspace members into groups for escalation targeting.

• Group notifications — notify all team members at once
• Escalation targets — use teams as step targets in escalation policies
• Simple membership — add and remove members without affecting other configurations

Read the full documentation | API Reference

Maintenance Windows

Schedule planned downtime with granular suppression controls.

• Alert suppression — silence notifications during planned maintenance
• Incident suppression — prevent incident creation entirely during maintenance
• Project scoping — target specific projects affected by the maintenance
• Recurring windows — cron-based recurrence for regular maintenance (e.g., weekly patching)
• Status page integration — auto-publish maintenance announcements
• Lifecycle management — SCHEDULED, ACTIVE, COMPLETED, CANCELLED states

Read the full documentation | API Reference

Expanded Notification Channels

Ionhour now supports 14 notification channel types, up from 2:

Read the full documentation

P1-P4 Incident Severity

Incidents now use a four-level severity model with per-check configuration:

• P1 (Critical) — default for DOWN transitions
• P2 (High) — available for custom configuration
• P3 (Medium) — default for LATE transitions and dependency impacts
• P4 (Low) — available for custom configuration

Each check can configure downSeverity and lateSeverity independently. Alert channels can filter by severity to route critical incidents to expensive channels (PagerDuty) while keeping lower-priority incidents in email.

Read the full documentation

Multi-Region Consensus

Outbound checks now use a documented consensus algorithm for multi-region monitoring:

• Majority voting for DOWN — a majority of regions must agree before declaring an outage
• Unanimous recovery — all regions must report success before resolving
• Staleness filtering — excludes regions that haven't reported within 2x the check interval
• Minimum quorum — requires at least 2 active regions for multi-region checks

Read the full documentation

6 Probe Regions

Outbound checks can now probe from 6 geographic regions:

Body Assertions

Outbound HTTP checks now support response body validation:

• Body contains — verify a string appears in the response
• Body not contains — verify a string does NOT appear in the response

This catches scenarios where an endpoint returns HTTP 200 but with error content.

Read the full documentation