One-time and recurring windows
Create an ad-hoc window for this deploy, or schedule a weekly maintenance slot that repeats on the same cadence without any manual intervention.
Schedule a maintenance window and Site Qwality mutes every alert on the affected monitors, posts a banner to your status page, and resumes alerting the moment the window closes, all automatically.
One window definition reaches every part of the stack: alerts stop firing, your status page shows a banner, and your on-call team isn't paged for expected work. When the window ends, everything returns to normal automatically.
Create an ad-hoc window for this deploy, or schedule a weekly maintenance slot that repeats on the same cadence without any manual intervention.
Every monitor targeted by the window stops generating alerts for the duration. Failures are still recorded internally, just not escalated to your team.
A maintenance banner appears on your public status page automatically before the window starts, giving users advance notice without you writing a separate update.
Apply a window to an entire environment tag (env:production or service:payments) instead of picking monitors individually. New tagged monitors are covered automatically.
Windows are specified in the timezone of your choice. Every team member sees the schedule in their local timezone so nobody does silent timezone math before a deploy.
When the scheduled end time passes, alert suppression lifts and monitoring resumes immediately. No manual step to "turn alerting back on" after a deploy.
Alert suppression is targeted and temporary. The window covers only the monitors you specify, only for the duration you set. If something genuinely breaks outside those monitors, or after the window closes, alerting is fully active.
One API call opens a maintenance window before your release pipeline deploys, and another closes it after the smoke tests pass. Wrap it in a script, drop it in CI, and you never silence alerts by hand again.
false pages fired during a correctly scoped window
every window is scheduled in a named time zone, not in UTC
recurrence types for repeating windows: weekly and daily
free tier, maintenance windows included from day one
No. Suppression is scoped only to the monitors you explicitly include. Monitors outside the window alert normally. Failures on covered monitors are still recorded so you can review them after the window closes.
Yes. A recurring window is either weekly, where you list the days it runs on, or daily. Either way you give it a start and an end time in HH:MM and an IANA timezone, and it repeats on that schedule. Cron expressions are not accepted: an earlier version of this page said they were, and they never have been.
When you create a maintenance window, an upcoming-maintenance banner appears on your public status page automatically. During the window, affected components show a "Maintenance" status rather than an outage. No separate status-page update is needed.
Yes. Tag your monitors by environment, service, or team, then apply the window to that tag. Any monitor added to the tag in the future is automatically covered by existing recurring windows.
Yes. One REST API call opens a window before a deploy starts and another closes it (or lets it expire) when the deploy finishes. Drop the two requests into your pipeline and alerts are suppressed only for the exact duration of the release.
Uptime, cron, synthetic, logs, RUM, incidents, and status pages. Free tier on every product.