Documentation Grafana Cloud Alerts and IRM Alerting Additional configuration Configure RBAC Configure silence access

Configure silence access

This article describes how Grafana Alerting controls access to silences and how to configure it for your teams. Use this article when you need to give some users full silence management while limiting others to silencing only their own rules.

Before you begin, ensure you have:

• Admin access to the Grafana organization
• Familiarity with Grafana RBAC and fixed roles

Silence types

Grafana Alerting has two types of silences:

• General silences — not attached to any specific alert rule. They can match alerts from any rule in the organization. Only users with org-scoped silence permissions can create them.
• Rule-specific silences — linked to a single alert rule via its UID. Access is controlled by the folder that contains the rule.

When you silence a firing alert directly from the alert list, Grafana creates a rule-specific silence automatically by adding the label matcher __alert_rule_uid__=<rule UID>. You can also create a rule-specific silence manually by including this matcher.

Silence permissions

Grafana has two independent sets of permissions for silences. They serve different purposes and apply to different scopes.

Org-scoped permissions

These permissions apply across the whole organization and cover both silence types.

The built-in Editor role includes all three via the fixed:alerting.instances:writer fixed role.

Folder-scoped permissions

These permissions are scoped to a specific folder. Users with only these permissions can manage rule-specific silences for rules in the granted folder, but can’t create general silences.

Fixed roles

The following fixed roles are relevant to silence management.

Folder permission mapping in Grafana OSS

In Grafana OSS, custom RBAC isn’t available. Instead, folder permissions automatically grant the corresponding silence access.

In Grafana Enterprise and Grafana Cloud, folder permissions grant the same silence access as in OSS, but you can go further by assigning folder-scoped RBAC permissions independently of rule access — for example, granting silence write access without granting rule write access.

Scenario: restrict users to rule-specific silences only

Use this setup when a team should be able to silence their own rules but must not create general silences that affect the whole organization.

Grant the following folder-scoped permissions for the team’s folder:

These permissions are included in fixed:alerting.rules:writer and are also granted automatically by the folder Edit permission.

Do not grant alert.instances:create or alert.instances:write at org scope — these allow creating general silences. They’re bundled into fixed:alerting.instances:writer and the built-in Editor role, so avoid assigning either to users who should be folder-restricted.

With this configuration:

• Users can create silences only for rules in their folder.
• Users can read all general silences.
• Any attempt to create a general silence is rejected.

Scenario: grant full silence access

Use this setup for on-call engineers or administrators who need full control over all silences.

Assign the following fixed roles:

Alternatively, assign the built-in Editor role, which includes both.

With this configuration:

• Users can create general silences for org-wide maintenance windows.
• Users can create and expire rule-specific silences for any rule.
• Users see all silences across the organization.

Security considerations

Keep the following in mind when configuring silence access.

• Org-scoped write actions are powerful. Granting alert.instances:create or alert.instances:write at org scope — even to a user who otherwise has only folder-level access — allows them to create or modify silences that affect the entire organization. Review all custom and inherited roles that include these actions.
• General silences are always visible to folder users. You can’t hide general silences from users who have any folder-scoped alert.silences:read permission. If general silences carry sensitive context (such as the name of an active incident), use clear, consistent naming conventions.
• Use rule-specific silences for team isolation. In multi-team or multi-tenant deployments, rule-specific silences are the recommended pattern. They respect folder boundaries, which general silences don’t.

Next steps

• Configure silences — create, edit, and expire silences
• Manage access using roles — full reference for fixed and custom roles
• Manage access using folders — folder-based access for alert rules and silences