Grafana silences and mute timings for maintenance windows

Grafana silences and mute timings: stopping notifications without stopping evaluation

Silences and mute timings both stop notifications, and neither stops Grafana from evaluating rules. That distinction matters during planned maintenance or recurring quiet hours, where you want pages suppressed but still want rule state, alert instances and dashboards to show what is actually failing. A *silence* is a one-off matcher on alert labels that mutes matching notifications for a set window, which suits a specific database upgrade or a planned network change. A *mute timing* is a recurring time interval attached to a notification policy route, which suits business-hours rules such as no non-urgent pages overnight on a team that does not staff nights. Choose the silence when the window is known and temporary, and the mute timing when the same quiet period repeats.

Because suppression hides notifications, the main risk is a silence that outlives the work it was created for or matches more alerts than intended. Before relying on either control, check the label matchers against the alert instances you expect to see, confirm the window's start and end times and time zone, and test a route that passes through the mute timing. Decide who may create silences, since a broad matcher such as one that matches every alert from a shared datasource can silence an unrelated outage. Restrict edit rights to the on-call or platform roles that own the affected services, and confirm how your Grafana role model and any Enterprise permission options apply to silence management in your edition.

The record of who silenced what, when, and why is what an auditor or incident reviewer will ask for, so plan it as part of the change process rather than after the fact. Ask your team to reference the change ticket in the silence comment, keep a copy of mute timing definitions in version-controlled provisioning files, and review silences that expired without a matching change. Confirm with your Grafana version's documentation how silence history and audit events are retained in your database and logs, because retention and export behavior vary with configuration and should be verified in your own environment before you depend on them.

Choosing between a one-off silence, a mute timing and a rule change

This table compares the three ways to stop or reduce notifications in Grafana Alerting: a one-off silence, a recurring mute timing, and changing or pausing the rule itself. Read each column as a different scope of control, and pick the narrowest option that covers the work, because each broader option can hide more than the maintenance you meant to cover.

Option	Best fit	Who usually owns it	Main risk of hiding a real incident
One-off silence	A known, time-limited change such as a single planned database migration or a dated patch window	The on-call engineer or the change owner for that system	Ends at a set time, but a silence that matches too broad a label set can mute unrelated alerts during the window
Recurring mute timing	A repeating schedule such as a weekly backup window or a nightly batch job that always produces the same alert	The platform or monitoring team, with approval from service owners	Keeps applying every cycle until someone removes or edits it, so a stale timing can suppress alerts long after the reason has gone
Rule change (edit, pause or delete)	A permanent fix to a noisy or wrong threshold, or a rule that no longer applies to the system	The rule author, reviewed by the owning team and recorded in version control where rules are provisioned	Removes evaluation entirely, so the condition is no longer tracked at all and recovery is not visible in Grafana
Notification scope	Silence and mute timing only affect notifications, while evaluation and alert state continue	Not applicable as an owner choice, but confirm this with your Grafana version	Teams may assume a silenced alert is still firing silently in the UI, so check the alert list during the window
Audit trail	Silences carry creator and expiry details, and mute timings are configuration objects	The team that approves maintenance changes	Edits made only in the UI may leave weaker evidence than a reviewed change, so confirm what history your setup keeps

Setting up a silence and a mute timing in a self-hosted instance

This sequence sets up a recurring mute timing on a notification policy and a one-off silence for a planned change, then proves each one with a test alert. The result is an instance where notifications pause on schedule while alerts keep evaluating and showing as firing in the UI.

Confirm the label scheme and target policy
The alert administrator checks which labels identify the systems in the maintenance scope, such as a team, service or environment label, and confirms which notification policy route those alerts follow. A mute timing or silence only affects alerts that match, so this mapping is the foundation for the rest of the sequence. Write the target labels down, and confirm them against a few live alert instances in the Alerting section before changing anything. Done when every alert in scope shows the same labels and the route it follows is recorded.
Create the mute timing
In the Alerting section, open the mute timings page and create a named timing with the recurring intervals that match your business hours or change window, including weekdays, times and time zone. Then attach it to the notification policy route that carries the in-scope alerts, using the mute timing option on that route. Save the change and confirm the timing appears on the route in the policy tree. Done when the timing is listed against the correct route and nothing else in the tree has changed.
Create the one-off silence
For a single planned change, create a silence from the silences page with matchers that copy the labels confirmed earlier, an explicit start and end time, and a comment naming the change request or ticket. Keep the matchers as narrow as the change allows, because a broad matcher hides unrelated alerts too. Confirm the silence shows the expected number of matched alert instances before saving. Done when the silence is active, lists the intended matchers and carries the ticket reference.
Fire a test alert inside the mute window
Trigger a test alert on a rule with labels that match the scope, either by temporarily lowering a threshold on a non-production rule or by using a test data source that returns a breaching value. Watch the Alerting section and the alert instance list while the window is active. The alert should move through its pending period and show as firing. Done when the instance appears in the UI as firing and the channel the policy normally uses receives no notification for it.
Check suppression on the contact point
Confirm the suppression on the receiving side by watching the destination channel, such as a chat room or paging tool, during the test. Also check the instance state in the UI, which should still read firing, so responders can see the condition is ongoing. If the test channel receives a message, review whether the mute timing is on the right route or whether a separate route sends the alert elsewhere. Done when the destination is silent and the UI still reports the instance as firing.
Verify the mute timing ends on schedule
Let the recurring mute timing reach the end of its active interval, or move the test alert outside the scheduled window according to your team's test procedure, and confirm that the next notification for the still-firing alert is delivered. Compare the actual delivery time with the timing you configured, including the time zone. Done when a notification is sent after the window closes and the time matches the configured schedule.
Confirm the silence expires and record the evidence
Check that the one-off silence moves to expired at its end time and that notifications resume for the same test alert. Then export or copy the silence details, the mute timing definition, the test results and the ticket reference into your change record. Ask your auditors which format they accept for this evidence before the first real change. Done when the expired silence, the mute timing and the test outcomes are stored together in the change record.

How matchers, policies and timings decide what gets muted

A silence in Grafana Alerting selects alert instances by their labels, using matchers such as alertname or team with an equality or regular expression test. Each firing alert instance carries the labels defined on its rule plus those added during evaluation, and the silence suppresses notifications for every instance whose labels match all of its matchers. A silence does not stop rule evaluation, so the alert still shows as firing in the Alerting views and the state history still records it. Before you create one, open the alert instances it would catch and confirm that the list contains only the systems in the maintenance scope. Expressions that match on a single broad label such as env=~".*" or a missing service label can silence far more than the work you planned, and that risk grows when the window is long.

A mute timing works differently. It is attached to a route in the notification policy tree and blocks notifications for that route during the times it defines, so it is a property of where alerts go rather than of which alerts fire. The notification policy matchers decide which route an alert reaches, and a mute timing on that route then decides whether the notification is sent at that moment. When a silence and a mute timing both apply to the same alert, the alert is suppressed by whichever mechanism matches first in your design, and in practice you should treat either one as sufficient reason to stay quiet. For a recurring business-hours pattern, a mute timing on a route is usually easier to maintain than a series of silences, because it does not need to be recreated each week.

The precision of both controls depends on label design on the rules. If the rule labels do not distinguish a database cluster from a web tier, or a production environment from a test one, no matcher can separate them without also catching unrelated alerts. Before the next maintenance window, confirm which labels each team's rules carry, check that the notification policy tree routes by those same labels, and decide who may create silences that match more than one team's alerts. Record the matchers, the expiry time and the approver in your change ticket, because the silence list is the only place the scope of a suppression is visible after it has ended.

Who should be allowed to create silences and mute timings

Silences and mute timings change what Grafana tells people, so the question of who can create, edit and expire them matters as much as the schedule itself. The cards below separate responder access from administrator access and cover the cleanup risk that comes with temporary suppression.

Separate responders from administrators

On-call responders usually need to silence a noisy alert during an incident, while platform administrators own mute timings that apply to whole teams or business hours. Decide which roles can create a silence for a single alert and which can change recurring mute timings or notification policies. Confirm in your own instance how the open-source edition maps roles to these actions, using the authentication and access control section of this hub as the reference point.

Limit who can edit and expire silences

A silence is only as trustworthy as the people allowed to change it. Restrict edit and delete rights on existing silences so that one person cannot extend another team's suppression without a record. Ask who receives the change history and whether a silence created by one role can be expired by another during an incident handover.

Set expiry on every temporary silence

A silence created for a maintenance window should end when the window ends, and it should carry a clear end time rather than relying on someone to remove it later. Require an end time or a short default duration for one-off silences, and review open silences at the end of each change. Silences that outlive the work hide real failures, which is the most common reason responders stop trusting alerts.

Control recurring mute timings

Mute timings repeat on a schedule, so a mistake in one changes every future notification in that window. Limit who can create or change them, and test each timing against the policy tree before it goes live. Document the owner of each mute timing, the teams it affects and the review date, so that a business-hours rule written for one team does not silently suppress another team's pages.

Record who suppressed what and why

Auditors and incident reviewers need to know who suppressed an alert, when, for which labels and under which change request. Ask whether your Grafana version records the creator and timestamp of each silence, and whether those records are retained long enough for your audit cycle. Where the built-in history is thin, require a change ticket reference in the silence comment and export the list of silences at the end of each window.

Keeping a record of silences for audits

A silence is only auditable if the record answers five questions: who created it, which matchers it applies to, when it starts and ends, which change ticket authorized it, and why it was needed. Grafana stores the matchers and the start and end times on the silence itself, but the creator, ticket and reason are not fields you can rely on unless your team agrees to put them in the comment and the ticket reference. Make the comment a required part of the silence creation process, and agree a format such as the change ticket ID first, then the owner and the purpose. A silence without a ticket reference should be treated as an exception that someone reviews afterward.

Grafana's own history is a starting point, not a complete audit trail. Confirm in your environment what the instance records about silence creation and edits, how long that data is kept, and whether it survives an instance rebuild or database restore, since configuration lives in the database you chose at installation. Confirm also whether the silence events reach your log platform, and whether that log platform keeps them for the retention period your change management policy requires. Many teams export a silence summary on a schedule and attach it to the maintenance change record, which gives the auditor one place to check the window against the approved change.

Decide early who owns the record. Change management usually owns the approval, the on-call lead owns the silence, and the platform team owns the Grafana configuration that controls who can edit silences. Write these responsibilities into the runbook, and test the trail once before you need it: create a silence for a dummy window, find every field in Grafana and in your external record, and confirm an outsider could reconstruct the event from those sources alone. Any compliance outcome that depends on this trail is for your auditor to judge, so ask them which evidence they expect before you design the format.

Questions teams ask before running maintenance windows in Grafana

How much effort does it take to set up silences and mute timings?

The effort depends mostly on how well your alert rules are labeled and how many notification routes you already run. A small instance with a handful of teams and consistent labels usually needs a short design session and a set of mute timings agreed with each owner. Teams with many routes, inconsistent label names or no agreed maintenance calendar spend most of the time on design and cleanup, not on the Grafana configuration itself. Ask any partner to size the work from your route tree and label inventory, not from a generic estimate.

What drives the effort up or down?

Four factors move the effort most:

The number of notification policy routes that need their own mute timings.
The quality of labels on alert rules, since silences match on labels.
The number of teams who own maintenance windows and need to approve them.
Whether mute timings must be provisioned as code or maintained through the UI.

Each factor adds design decisions and testing. Clean labels and a single owner per route keep the work small and predictable.

Can our internal team set up maintenance silences without outside help?

Yes, if your engineers understand Grafana notification policies and can test changes safely. The Grafana UI and the provisioning files both support silences and mute timings, so an internal team can build them. Outside help is most useful when the design is contested across teams, when rules lack labels, or when you want the configuration stored as code and reviewed like other infrastructure. Whichever route you choose, agree on who may create and approve silences before the first window.

How long does the work take for a typical scope?

No duration is fixed for this topic, so treat any timeline as provisional until the scope is written down. A narrow scope covering one team and a single recurring business-hours mute is quick to build and test. A wider scope covering several routes, one-off maintenance silences, approval steps and audit records takes longer because each part needs review. Fixed-scope engagements are agreed in writing before work starts, so ask for the timeline as part of that written scope.

What must we provide before the work starts?

You will need to provide a current inventory of alert rules and their labels, your notification policy tree, the list of contact points and the teams that own each route. You should also share your maintenance calendar, including recurring change freezes, business hours and public holidays, plus the names of people allowed to approve silences. Missing calendar data is the most common reason mute timings end up wrong, so gather it before any configuration begins.

Who should be allowed to create silences and mute timings?

Restrict creation to the on-call or platform roles that own the affected routes, and let service owners request windows through them. Use Grafana's role-based access controls to separate people who edit notification policies from those who only create silences. Require a reason and an end time on every silence so that stale silences expire rather than hide problems indefinitely. Confirm the exact permissions available in your Grafana edition and version before you write the access model.

How do we keep an audit record of silences and mute timings?

Keep a record outside the silence itself: who requested each window, who approved it, the start and end times, the affected routes, and the business reason. Store mute timings and policies in version control through provisioning so every change has a commit history. Review expired silences on a regular schedule and compare them with incident records. Ask your auditor which evidence they expect, since Grafana prepares the controls and logs but does not issue audit conclusions.

Limits to confirm in your Grafana version and environment

Silences and mute timings look simple in the UI, but how they behave depends on your Grafana release, your database and how many instances you run. The cards below list the behaviors to confirm against the exact version you operate, before a maintenance window depends on them.

Silence sharing across HA nodes

In a high availability setup, confirm whether a silence created on one Grafana instance is visible and enforced on every other node. Silences are alert routing state, so a gap here means some nodes keep notifying during the window you meant to quiet. Run a controlled test: create a silence on one node, trigger a test alert, and confirm no notification leaves from any node. Also check how the nodes share alerting state, since the high availability docs say alerting needs extra configuration to avoid duplicate notifications.

Silence expiry and editing behavior

Confirm how a silence ends, how its end time is stored, and whether an active silence can be edited or extended after it starts. A silence that expires early will page people in the middle of planned work, and one that never expires can hide a real fault after the work is finished. Test a short silence in a non-production instance and watch the end time in the UI and in the API response. Record the behavior for your release so the on-call team knows what to expect.

API and provisioning support

Confirm whether your release lets you create, list and expire silences and mute timings through the API, and whether file provisioning or your as-code tool can manage them. If they can be managed as code, the maintenance calendar can live in version control with review and an audit trail. If they cannot, plan a manual change record and a scheduled export of current state. Ask the vendor or check the provisioning docs for the exact resource names and supported fields in your version.

Time zones and daylight saving

Mute timings are defined as recurring time ranges, so check which time zone each timing uses and how it handles daylight saving transitions. A window set for 02:00 local time can fire an hour early or late on the day clocks change, or skip entirely if the rule is written against an offset. Confirm the time zone field format in your release, then test a timing across a transition date using a dated test rule. Document the zone in the timing name so reviewers can read it without opening the configuration.

Permissions to create and expire

Confirm which roles can create silences, edit mute timings and delete either object in your release, and whether those permissions are set per folder, per organization or globally. Permission models differ between open-source and Enterprise editions, so check the role mapping in your own instance. Limit silence creation to on-call leads and the change owner, and test that a viewer or standard editor cannot widen a silence to cover unrelated rules.

Audit trail coverage

Confirm what Grafana records when a silence or mute timing is created, changed or removed, including the user, the timestamp and the matchers or times involved. Check whether this lives in the Grafana server logs, a database table or an external audit feed, and how long it is kept. Many compliance reviews need the reason for a silence as well as the action, so confirm whether the comment or annotation field is stored and whether it survives an upgrade.

How DeployOpen scopes and delivers alert suppression work

DeployOpen plans and implements Grafana silences and mute timings as part of a self-hosted Grafana instance inside your own infrastructure. We agree the suppression rules, who may create them and how each change is recorded in writing before any configuration changes, so maintenance quiet periods stop notifications without hiding rule evaluation.

How we scope

The written scope lists which maintenance windows, recurring business-hour mute timings and teams the suppression design covers.
We confirm which notification policies and contact points each mute timing and silence will apply to in your instance.
Scope records who may create silences, who approves recurring mute timings and what audit record each change must leave behind.

How we build

We configure mute timings as code or through provisioning where your team wants changes reviewed in version control.
We test silence creation, expiry and routing on a non-production Grafana instance before any change reaches production.
We verify that rule evaluation and state history continue during muted periods, so suppression never hides the underlying condition.

How we hand over

Deliverables include a runbook for creating, extending and expiring one-off silences during planned maintenance.
We document the mute timing definitions, their time zones and the owners who approve changes to them.
Handover covers the audit procedure, including where silence records are kept and how to export them for review.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Support can cover reviewing mute timings after organizational changes, such as new shifts or regional holidays.
Engagements are fixed-scope, and any change to the agreed silence or mute timing design is scoped in writing before work starts.