[PLUS] Global mute is an Enterprise Edition (PLUS) exclusive feature of Nightingale.

Overview

Global mute = a mute rule that takes effect by default across all business groups.

Sidebar path: Alerts → Rule Management → Global Mute tab, URL /global-muting-rules.

Differences from “Mute Rules”:

Dimension	Mute Rules (OSS + PLUS)	Global Mute (PLUS)
Scope	Bound to a single business group; only takes effect on events in that business group	Effective by default on all business groups across the entire instance
Scope control	Choose “applicable business groups / data sources” as whitelist	Choose “exclude business groups / data sources” as blacklist
Use case	Business teams suppress their own known noise	Platform admins uniformly handle large-scale cross-business maintenance (e.g., data center power outage, network changes, release windows)
Entry point	“Mute Rules” inside a business group context	Global Mute tab (Admin role only)

Typical use cases:

• A weekend midnight data-center power outage drill across all business groups — configure a global mute in advance, and stay silent throughout the window;
• A common metric (e.g., target_miss) is uniformly suppressed during a centralized maintenance window in some IDC;
• Cross-business-group change windows: exclude business groups affected by changes during a release; others continue to alert as usual.

Create / Edit Global Mute

The page header has a Pro tag — if you don’t see it, your instance is not a PLUS edition.

The form is divided into 3 sections:

① Basic Info

Field	Required	Description
Mute Reason	No (but strongly recommended)	Clearly state “why mute + who is responsible + expected recovery time”; this is what’s shown in the list

② Filter Conditions

Define “which events are muted after they hit.”

Field	Required	Description
Event Labels	Yes (at least 1)	Label matching condition; click the + button to add a row. Each row supports = (equals), != (not equals), =~ (regex), !~ (regex non-match). Multiple rows are AND-combined. For example, env=prod + service=api means both must be satisfied
Excluded Business Groups	No	Blacklist — selected business groups will not be muted. Empty means “all business groups are muted”
Excluded Data Sources	No	Blacklist — selected data sources will not be muted. Empty means “all data sources are muted”

Event labels are the most critical basis for global mute to take effect — leaving it empty will fail to save (backend will report “tags is blank”). Always have at least one label condition to avoid accidentally muting all alerts.

③ Mute Duration

Supports two time modes:

Fixed time (default): choose a continuous time window.

• Mute duration: quick options like 1h / 6h / 24h / 7d;
• Mute start time / mute end time: auto-calculated from the duration, can also be manually edited to any range;
• When the end time is reached, the rule automatically expires and needs to be re-enabled or newly created.

Periodic time: mute every week at fixed time slots, with long-term effect.

• Mute time: multi-select Monday to Sunday on the left (click ❌ to deselect)
• Start time / End time: HH:MM of the day, e.g., 00:00 to 06:00 means every day 0-6 a.m.
• Click the + button to add multiple time slots (e.g., nighttime + weekend)

Periodic mode is commonly used for ongoing scenarios such as “long-term nighttime maintenance window” or “weekday lunch break silence”; for one-off temporary mute, fixed time is more intuitive.

Operations & Behavior

• Enable / Disable: toggle the Switch directly in the list; once disabled, the rule is retained but no longer takes effect.
• Delete: the rule disappears after deletion; keep + disable if you want to reuse it as a template.
• Effective relationship: an event ∪ global mute ∪ the business group’s local mute rules — as long as any mute rule hits, no notification is generated.

FAQ

Q1: I misconfigured a global mute and silenced all alerts on the entire platform — how do I urgently stop the bleeding?

A: Go into the list and turn off the “Enable” switch for that rule — effective in seconds. This is why “mute reason” should clearly indicate the responsible person + expected recovery time, so on-call colleagues can quickly judge whether to disable it. Never configure a rule with “Event Labels = __name__=~.+” + no exclusions — that’s equivalent to turning off all platform alerts.

Q2: If global mute and a business-group-level mute rule exist at the same time, how many times will the event be muted?

A: Mutes are OR-related; as long as any mute rule hits, the event is suppressed; there’s no repeated muting. So both rule sets can coexist: the platform handles large-scale cases (e.g., data center maintenance), while business teams handle their own known noise.

Q3: After a mute rule takes effect, will the original alert events still appear in the “Active Alerts” list?

A: No. Muted events do not generate alert events, no notifications are pushed, and they do not appear in the active alerts list. To see “how many events there would be if not muted,” you can review historical alert recovery events after the mute rule expires.

Q4: How do I write a periodic time mode that spans days (e.g., 22:00 to 06:00 the next day)?

A: It is recommended to split it into two segments: Monday to Sunday 22:00-23:59 + Monday to Sunday 00:00-06:00. The current UI does not support a single segment spanning days.

References

• Mute Rules (Business Group Level)
• Alert Rules
• Active Alerts