You are about to run a database migration. Or push a major deployment. Or rotate TLS certificates. You know the site will be down for a few minutes, maybe longer. The last thing you need is your monitoring tool flooding Slack with alerts, paging the on-call engineer, and creating incidents for downtime you planned and expected.
This is the exact problem maintenance windows solve. They let you tell your monitoring system: "I know this is going to be down. Do not alert me." CronAlert's maintenance windows silence alerts during a defined time range while continuing to run checks and log results, so you keep full observability without the noise.
How maintenance windows work
A maintenance window is a start and end timestamp attached to a monitor. While the current time falls within that window, CronAlert changes its behavior in two specific ways:
- No alerts are sent. Even if a check returns a non-200 status code, times out, or fails a keyword match, CronAlert will not send notifications to any of your alert channels -- email, Slack, Discord, webhooks, Telegram, PagerDuty, or anything else you have configured.
- No incidents are created. Failures during the maintenance window do not open new incidents. Your incident history stays clean, reflecting only genuine unplanned outages.
Critically, checks still execute on their normal schedule and results are still logged. This means you can look back at the maintenance period and see exactly what happened: how long the endpoint was unreachable, when it came back, and what the response times looked like during recovery. You lose nothing in terms of data -- you just skip the alerts.
Once the maintenance window ends, CronAlert clears the timestamps and resumes normal operation. If the next check after the window detects a failure, alerting kicks in immediately. There is no manual step to "end" maintenance mode. Set the window, do your work, and the system handles the transition back automatically.
Setting up a maintenance window
Maintenance windows are configured directly on each monitor through the create or edit form. There is no separate scheduling interface or calendar view -- it is just two date fields on the monitor itself.
- Go to your CronAlert dashboard and either create a new monitor or edit an existing one.
- Find the Maintenance Window section in the monitor form.
- Set the Start date and time for when maintenance begins.
- Set the End date and time for when maintenance concludes.
- Save the monitor.
That is all there is to it. The monitor continues running checks on schedule, but any failures between the start and end timestamps are silently logged without triggering alerts or incidents. After the end timestamp passes, the maintenance window fields are cleared and the monitor returns to its normal alerting behavior.
Maintenance windows are available on every CronAlert plan, including the free tier. There is no upgrade required to use this feature.
When to use maintenance windows
Any time you expect planned downtime, a maintenance window is the right tool. Here are the most common scenarios.
Database migrations
Schema changes, data migrations, and database version upgrades often require taking the application offline or restarting connections. If your app returns errors while the migration runs, a maintenance window prevents those expected errors from generating noise. You can review the check logs afterward to confirm the migration completed within your expected timeframe.
Infrastructure upgrades
Swapping out load balancers, upgrading server instances, migrating to a new hosting provider, or changing DNS records all carry a window of expected downtime. Even "zero-downtime" infrastructure changes can produce brief blips that trigger sensitive monitors. A maintenance window gives you a buffer.
TLS certificate renewals
Most certificate renewals are automated and seamless, but manual renewals or certificate authority migrations can cause brief HTTPS failures. If you know you are rotating certificates at a specific time, set a maintenance window to cover it. This is especially useful if your monitors check SSL certificate validity, since the certificate may briefly appear invalid during the swap.
Deployment windows
If your deployment process involves restarting application servers, clearing caches, or running post-deploy health checks, there may be a brief period where endpoints return errors. For teams that deploy on a regular schedule -- say, every Tuesday at 2 PM -- you can set a short maintenance window around that time to absorb any deployment blips.
Load testing
Running a load test against a production or staging endpoint can push response times beyond your monitor's timeout threshold or cause intermittent failures under heavy load. A maintenance window lets the load test run without contaminating your incident history. The check results still log response times, so you can correlate your load test metrics with what your monitoring observed.
Best practices
Pad your maintenance window
If you expect a migration to take 30 minutes, set the maintenance window for 45 minutes or an hour. Maintenance rarely finishes exactly when you think it will. A buffer prevents the situation where your endpoint is still recovering when the window closes and alerts start firing for the last few minutes of planned work. It is much easier to finish early inside a window than to scramble to extend one while alerts are going off.
Combine with status page updates
If you run a public status page for your users, maintenance windows and status page incidents work well together. Create a status page incident to inform your users about the planned maintenance, then set a maintenance window on the affected monitors to suppress internal alerts. Your users know what is happening, and your team is not bothered by expected failures. After the maintenance is complete, update the status page incident to resolved.
Scope windows to specific monitors
Maintenance windows are set per-monitor, not globally. Take advantage of this granularity. If you are only migrating one database that serves one API, set the maintenance window on that API's monitor rather than silencing everything. This way, if an unrelated service goes down during your maintenance, you still get alerted about it. Only silence the monitors you know will be affected.
Review check results after maintenance
Since CronAlert continues logging check results during the window, make it a habit to review those results once maintenance is complete. Verify that the endpoint recovered within your expected timeframe and that response times returned to normal. If the check results show the endpoint was down longer than expected, that is useful information for planning future maintenance windows.
Frequently asked questions
Do checks still run during a maintenance window?
Yes. CronAlert continues executing checks and logging results throughout the maintenance window. The only difference is that alerts are suppressed and no incidents are created. You get full visibility into your endpoint's behavior during the maintenance period without any noise. This is an intentional design choice -- the data is valuable even when you do not want the notifications.
Are maintenance windows available on the free plan?
Yes. Maintenance windows are available on all CronAlert plans, including the free tier. Every monitor, regardless of plan, can have a maintenance window configured.
What happens if my site is still down after the maintenance window ends?
Normal alerting resumes immediately once the window closes. If the next scheduled check after the window's end timestamp detects a failure, CronAlert creates an incident and sends alerts through your configured channels. There is no grace period or cool-down after a window ends -- the system treats it as if the monitor was never in maintenance. This means you should set your window long enough to cover the full expected downtime, including recovery time.
Do maintenance windows work with multi-region monitors?
Yes. Maintenance windows apply to the monitor regardless of its check configuration. If you have a monitor running multi-region checks across five regions, all regional probes continue executing during the window and all results are logged. But no region's failure will trigger an alert or create an incident until the window ends. The suppression is at the monitor level, not the region level.
Planned downtime does not have to mean alert fatigue
Every ops team has been there: you are in the middle of a planned migration, Slack is exploding with alert notifications, and someone has to reassure the rest of the team that yes, this is expected, please ignore it. Maintenance windows eliminate that entirely. Your monitoring keeps doing its job -- running checks, collecting data, tracking response times -- without generating alerts for downtime you already know about.
Set the window before you start, do your work, and let the system handle the rest. When maintenance is over, alerting picks back up automatically. No manual toggling, no remembering to re-enable notifications, no risk of leaving a monitor silenced by accident.