Important: This documentation is about an older version. It's relevant only to the release noted, many of the features and functions have been updated or replaced. Please view the current version.

Open source

(Optional) Grafana Mimir ruler

The ruler is an optional component that evaluates PromQL expressions defined in recording and alerting rules. Each tenant has a set of recording and alerting rules and can group those rules into namespaces.

Operational modes

The ruler supports two different rule evaluation modes:


This is the default mode. The ruler internally runs a querier and distributor, and evaluates recording and alerting rules in the ruler process itself. To evaluate rules, the ruler connects directly to ingesters and store-gateways, and writes any resulting series to the ingesters.

Configuration of the built-in querier and distributor uses their respective configuration parameters:

Note: When this mode is used, no query acceleration techniques are used and the evaluation of very high cardinality queries could take longer than the evaluation interval, eventually leading to missing data points in the evaluated recording rules.

Architecture of Grafana Mimir’s ruler component in internal mode


In this mode the ruler delegates rules evaluation to the query-frontend. When enabled, the ruler leverages all the query acceleration techniques employed by the query-frontend, such as query sharding. To enable the remote operational mode, set the -ruler.query-frontend.address CLI flag or its respective YAML configuration parameter for the ruler. Communication between ruler and query-frontend is established over gRPC, so you can make use of client-side load balancing by prefixing the query-frontend address URL with dns://.

Architecture of Grafana Mimir’s ruler component in remote mode

Recording rules

The ruler evaluates the expressions in the recording rules at regular intervals and writes the results back to the ingesters.

Alerting rules

The ruler evaluates the expressions in alerting rules at regular intervals and if the result includes any series, the alert becomes active. If an alerting rule has a defined for duration, it enters the PENDING (pending) state. After the alert has been active for the entire for duration, it enters the FIRING (firing) state. The ruler then notifies Alertmanagers of any FIRING (firing) alerts.

Configure the addresses of Alertmanagers with the -ruler.alertmanager-url flag, which supports the DNS service discovery format. For more information about DNS service discovery, refer to Supported discovery modes.


The ruler supports multi-tenancy and horizontal scalability. To achieve horizontal scalability, the ruler shards the execution of rules by rule groups. Ruler replicas form their own hash ring stored in the KV store to divide the work of the executing rules.

To configure the rulers’ hash ring, refer to configuring hash rings.

HTTP configuration API

The ruler HTTP configuration API enables tenants to create, update, and delete rule groups. For a complete list of endpoints and example requests, refer to ruler.


The ruler uses the backend configured via -ruler-storage.backend. The ruler supports the following backends:

Local storage

The local storage backend reads Prometheus recording rules from the local filesystem.

Note: Local storage is a read-only backend that does not support the creation and deletion of rules through the Configuration API.

When all rulers have the same rule files, local storage supports ruler sharding. To facilitate sharding in Kubernetes, mount a Kubernetes ConfigMap into every ruler pod.

The following example shows a local storage definition:


The ruler looks for tenant rules in the /tmp/rules/<TENANT ID> directory. The ruler requires rule files to be in the Prometheus format.