Plan an update without losing sight of your service
A planned restart can look like an unexpected outage to a monitoring rule. If you silence everything manually, it is easy to forget to turn notifications back on. If you leave every destination active, an expected interruption can send unnecessary messages to the people doing the work.
MetriBeacon maintenance schedules give that interruption a defined scope and end. Measurements and alarm states continue to be recorded while notification delivery for affected monitors is suppressed. You can still investigate what happened during the update and check whether the service recovered afterward.
This guide covers private workspace maintenance: one-time or weekly schedules for selected monitors, groups or the whole workspace. Public announcements and maintenance attached to an individual alarm rule have separate behavior.
What is a monitoring maintenance window?
A maintenance window is a bounded period for planned work, such as a server reboot, database update or application deployment. In MetriBeacon, a workspace maintenance schedule determines when and where related alarm notifications are suppressed.
It does not execute your update, stop data collection or turn a failed observation into a successful one. A website check can still record an unavailable response, and server measurements can still show the effects of a restart. An incident and its suppressed delivery remain different facts.
Keep the scope close to the work. If you are updating one service, select its monitors or a carefully maintained group. Choose the whole workspace only when all of its monitoring should share the notification pause.
Create a one-time maintenance schedule in MetriBeacon
Open the intended workspace and select Maintenance in the sidebar. You need permission to edit that workspace. If the section is unavailable, check access and feature availability before changing individual alarm rules instead.
- Select Schedule maintenance and enter a useful private name.
- Leave Enabled selected when the schedule should take effect.
- Choose One-time and enter its start and end using the displayed timezone.
- Choose the affected resources: individual monitors, groups or the entire workspace.
- Review the selected resources, particularly if a group contains unrelated services.
- Save, then check the occurrence shown in the maintenance overview.
- Compare that interval with the actual work plan before starting the update.
For example, plan a checkout service update for Tuesday from 09:00 to 09:30 in the displayed local zone. Cover the checkout monitors while leaving an unrelated mail service outside the selection. If the work changes, edit the schedule deliberately rather than assuming the original end will extend itself.
A workspace supports up to 20 schedules, including disabled ones. Each window can last at most seven days. These are technical limits, not a recommendation to create a broad week-long pause for a short update.
Schedule weekly maintenance with an explicit timezone
For regular work, choose Weekly and set the weekday, local start time, IANA timezone and duration in minutes. A name such as Europe/Berlin expresses a local time policy; a fixed UTC schedule expresses a different one.
Check the upcoming occurrences after saving. The schedule's zone and the zone used to display dates need not be the same. A screenshot containing only “09:00” is therefore not a complete maintenance plan.
MetriBeacon skips a local start time that does not exist during a clock change. When a local start time occurs twice, it uses the first occurrence. Duration means elapsed time: a 30-minute window lasts 30 actual minutes even when the displayed local clock changes.
If a particular maintenance must take place despite a skipped local time, arrange a suitable explicit occurrence in advance. Do not rely on the weekly schedule to invent a replacement start. Review selected groups when their membership changes, too; changing membership can change which monitors are covered going forward.
Choose maintenance, mute or pause for the intended job
These controls are related, but their effects differ. The maintenance, pause and mute guide explains the rule-level controls.
| Control | Intended effect |
|---|---|
| Workspace maintenance schedule | Keep measurements and alarm states while suppressing delivery for the affected monitors during the window. |
| Mute an alarm rule | Keep incidents visible while suppressing that rule's notifications until the chosen time. |
| Pause an alarm rule | Stop evaluating that rule until it is resumed. |
| Maintenance on an individual rule | Pause new alarm and recovery transitions for that rule during its window. |
| Public maintenance notice | Inform status-page visitors through separately reviewed and published content. |
This distinction matters when investigating a missing message. Removing a workspace schedule does not remove an independent rule mute or rule maintenance window. Check all applicable controls rather than repeatedly sending notification tests.
Keep availability and data coverage honest
An expected outage is still an observation about your service. Workspace maintenance does not erase it or fill a data gap with healthy time. Read SLOs and error budgets together with the selected period and data coverage.
Where a report offers maintenance-adjusted availability, treat that as a separate view with an explicit exclusion policy. It is not interchangeable with availability that includes the interruption. Use the same policy when comparing periods so that a change in maintenance settings does not look like a service improvement.
Maintenance also does not prove that a job completed. For scheduled jobs, affected expected slots can be skipped during workspace maintenance; an unobserved run does not become a successful backup. Continue checking actual backup results after the work.
Check the service again when maintenance ends
At the end of the window, MetriBeacon checks current conditions again. A still-current, unacknowledged problem can produce a deferred notification when the other delivery requirements allow it. Resolved or stale conditions should not revive an old outage.
Do not use silence alone as evidence that the update succeeded. Review the monitor's latest result, freshness, open incidents and delivery history. For a website, check the meaningful application response as well as whether the server is reachable.
If a message is missing, look for an overlapping maintenance schedule, a remaining mute, a paused rule or monitor, a destination issue or a delivery allowance. The email and Telegram guide helps with destination setup; other channels use the same need for a deliberate rule assignment.
Publish a separate maintenance notice for visitors
Private maintenance is not automatically a public announcement. When visitors need advance notice, use Prepare public maintenance notice for an upcoming occurrence and choose the status page and public components.
Write a public title and description. Private names and targets are not copied. Save the draft, then have a permitted status-page publisher review and explicitly publish it in the maintenance editor. Preparing a notice alone does not make it public.
The prepared draft concerns the next occurrence. Later private edits do not update it, and a weekly internal schedule does not automatically publish an announcement for every week. Review the notice again if the start, duration or affected service changes. The status-page guide explains how to share approved service information.
A practical checklist for your next update
Before starting, confirm scope, start, end, timezone and the next displayed occurrence. Tell the responsible people which service is affected and where they should check progress. Keep unrelated monitoring outside the window.
During the work, follow real measurements and incidents. If the update overruns, make a conscious scheduling decision. Afterward, check a fresh application result, review any remaining incident and make sure a public notice reflects the outcome.
For the first setup, practice with an owned test monitor and an agreed notification destination. Avoid experimenting with production-wide selections or real recipient tests without coordinating them.
Frequently asked questions about maintenance windows
Does maintenance stop MetriBeacon collecting measurements?
No. Workspace maintenance keeps measurements and alarm states while suppressing the affected notification delivery. Pausing an alarm rule has a different purpose.
Does a weekly schedule keep the same local start time?
It uses the configured weekday, local time and IANA timezone. Missing local times are skipped, repeated local times use their first occurrence, and the duration is elapsed time. Review the upcoming dates around clock changes.
Will an unresolved problem notify me after maintenance?
A current, unacknowledged problem can be notified after the window when the remaining rule and delivery conditions allow it. Check freshness, other suppression controls and the delivery history; there is no reason to expect every historical message to be replayed.
Are maintenance windows free with MetriBeacon?
MetriBeacon is free within its documented technical quotas. Workspace maintenance has the schedule and duration limits described above, and it does not remove other account or delivery limits.
Start with a focused maintenance window
Create a free MetriBeacon account, connect a monitor and schedule the smallest useful maintenance scope for your next update. Keep the resulting measurements, check recovery and publish a separate notice when visitors need one. The Website/API template below creates a complementary monitor; configure its maintenance separately under Maintenance.
