2026-04-01

Maintenance Window Best Practices to Prevent False Alerts

maintenance window uptime monitoring alert management

False Alerts During Maintenance Are Costing You Time

Every web agency has been there. You schedule a server migration or CMS update for a client site at 2 AM, and your monitoring tool floods Slack with alerts. By morning, your team is desensitized to notifications and slower to respond to real incidents. This is alert fatigue, and it is a serious operational risk.

Miterl's maintenance window feature lets you register planned downtime in advance so that alerts are automatically suppressed during that period.

What Is a Maintenance Window?

A maintenance window tells your monitoring system: "This downtime is planned." During the configured window, Miterl behaves as follows:

Monitoring checks continue to run as normal
Alert notifications are suppressed
If the site is still down when the window ends, an alert fires immediately

This means you never lose visibility. If maintenance runs longer than expected, you will know right away.

Best Practices for Configuration

1. Add Buffer Time Before and After

If your maintenance is scheduled from 11:00 PM to 1:00 AM, set the window from 10:50 PM to 1:15 AM. DNS propagation, cache invalidation, and CDN purges can cause brief downtime outside your exact maintenance period.

2. Automate via Webhook

Integrate maintenance window start and end calls into your CI/CD pipeline so no one forgets. Each monitor has its own maintenance webhook token, so a single token-based URL opens the window before deployment. You can generate and view the token from the monitor's settings in the dashboard.

# Open a maintenance window before deployment (duration_hours 1-24, defaults to 4)
curl -X POST https://miterl.com/api/v1/webhooks/maintenance/YOUR_TOKEN/start \
  -H "Content-Type: application/json" \
  -d '{
    "duration_hours": 1,
    "name": "Server migration"
  }'

When the deployment finishes, send the end request to close the window. If the work wraps up early, you can return to normal monitoring without waiting for the duration to elapse.

# Close the maintenance window once the deployment finishes
curl -X POST https://miterl.com/api/v1/webhooks/maintenance/YOUR_TOKEN/end

Because the token is scoped to a single monitor, you suppress exactly the right site and nothing else. To maintain several sites at once, send a start request for each monitor's token.

3. Scope Windows to Specific Monitors

Apply the window only to the monitors under maintenance. Blanket suppression across all sites means you could miss a real outage on an unrelated client site.

4. Use Recurring Schedules

If a client has a weekly batch job every Wednesday at 3 AM, configure a recurring maintenance window in the dashboard (weekly, on the chosen day, time, and duration) instead of creating one manually each week. Set it once, and alerts during that window are suppressed automatically going forward.

For irregular maintenance such as deployments, use the per-monitor webhook token from the previous section to open and close the window from CI/CD on demand. A simple rule of thumb — recurring tasks go in the dashboard schedule, ad-hoc deployments use the webhook — keeps you from ever forgetting to set one.

Use Maintenance History for Client Reporting

Maintenance window history is visible in the Miterl dashboard. When a client asks about downtime in their monthly report, you can clearly distinguish planned maintenance from actual incidents. Planned downtime is automatically excluded from uptime calculations, giving you accurate SLA reports without manual adjustments.

Handling Overnight Maintenance Windows (Crossing Midnight)

Maintenance that runs from 11:00 PM to 1:00 AM the next day is a common source of misconfiguration. Miterl defines windows by start time and duration (in minutes or hours) rather than a separate end time. Specifying "start 23:00, duration 2 hours 30 minutes" works correctly across midnight without any special handling.

Recurring schedules work the same way: start time plus duration. You never need to think about whether the end time falls on the next day, which eliminates a whole category of setup errors.

Team Workflow Rules for Multi-Agency Environments

When your agency manages ten or twenty client sites, "who sets the maintenance window" and "how do we avoid forgetting it" need to become explicit team policies, not individual habits.

Patterns that work well in practice:

Embed it in deployment scripts: Make the webhook call a fixed step in your deploy shell script or CI/CD workflow so it can never be skipped manually
Add it to your pre-flight checklist: Include a "maintenance window set?" item in your pre-deployment checklist to prevent knowledge from living in one person's head
Broadcast window open and close to Slack: With a Slack alert contact configured in Miterl, the whole team sees when a window opens and closes, keeping everyone aligned without extra communication overhead

For how maintenance history ties into monthly client reporting and SLA calculations, see the uptime SLA report guide.

Summary

Properly configured maintenance windows reduce false alerts, lower team stress, and give your clients clear accountability. With Miterl, you can automate the entire process through the API and integrate it directly into your deployment pipeline.

A natural companion to maintenance windows is heartbeat monitoring -- a way to verify that your scheduled batch jobs and auto-renewal scripts actually ran. If a cron job silently fails during a maintenance window, heartbeat monitoring catches it. For a detailed walkthrough, see "Heartbeat Monitoring: How to Verify Cron Jobs Are Running."

Check the documentation for detailed setup instructions. Try the feature yourself by signing up for free, and see how other agencies use Miterl on the use cases page.