Import Prometheus, Mimir and Loki alert rules into Grafana

Import Prometheus alert rules into Grafana-managed alerting without a gap in coverage

Your alert rules currently run inside Prometheus, Mimir or Loki ruler configuration, and the goal is for Grafana to own evaluation and notification routing. The effort depends on three things: how many rules you have, how many of them use options that Grafana-managed rules do not carry over, and how much of your routing logic has to be rebuilt in Grafana contact points and notification policies. Treat the work as a controlled cutover with a parallel run, where the old and new rules evaluate side by side until you have shown that they fire on the same conditions. Switching off the source rules before that comparison is the usual way coverage gaps appear. There are three documented paths for the import. The Alerting UI lets you bring in data source-managed rules interactively, which suits small sets and one-off reviews. mimirtool and cortextool are command-line tools for pulling rule groups from a Mimir or Cortex ruler and loading them into Grafana, which suits larger sets and repeatable runs. Confirm in the current Grafana Alerting documentation which rule types and fields each path supports for your Grafana version, because the three paths do not handle every option in the same way. Before you choose a path, export the source rules and list every option on each one, then mark the options that have no Grafana-managed equivalent. Decide who owns the routing labels and which notification policy each rule will land in, because imported rules keep their labels but do not keep the routing your Alertmanager applied. Confirm the permissions needed to create rules in the target folders, and make sure the notification path is tested before either side is silenced.

What maps cleanly from data source-managed rules and what does not

This table compares the parts of a Prometheus, Mimir or Loki ruler configuration against their Grafana-managed equivalents, so you can see which pieces carry over directly and which need redesign. Read each row as a checklist item to verify against the Grafana alerting documentation for your version before you plan the cutover. The main takeaway is that the rule expressions usually move cleanly, while evaluation timing, namespace layout and routing need deliberate rework.

Element	Source-managed rules	Grafana-managed rules	Action for migration
Alerting rule expressions	PromQL or LogQL expressions in rule files	Queries against the data source, evaluated by Grafana	Usually portable, but test each expression against the same data source in Grafana
Recording rules	Precomputed series written by the ruler	Not a direct equivalent in every setup	Confirm support for your version; keep recording rules in the source ruler if needed
Rule groups and evaluation interval	Each group evaluates its rules sequentially at one interval	Rules are organized into groups with their own interval	Recheck how sequential evaluation affects timing and dependent rules
Labels	Labels on alerts set by rule definition	Labels drive routing and matching in notification policies	Map each label that routing depends on before rewriting policies
Annotations	Summary and description text on each alert	Annotations carried on the Grafana rule	Usually carried over, but verify template syntax renders the same
Namespace and tenant layout	Files or namespaces scoped per tenant in Mimir or Loki	Folders and organization-level permissions in Grafana	Redesign folder structure and permissions; tenant isolation does not carry over automatically
Alertmanager routing	Routes and receivers in Alertmanager configuration	Notification policies and contact points in Grafana	Rebuild routing by hand; matching logic does not translate one to one
Silences and inhibition	Managed in Alertmanager	Managed through Grafana alerting features	Recreate active silences and inhibition rules; confirm equivalents for your version

Which documented import path fits Prometheus, Mimir or Loki rules

Rules defined in Prometheus rule files are the easiest source to read because they are plain YAML listing groups, alerting rules and recording rules. Grafana does not import those files as Grafana-managed rules, so the work is translation. Each rule's PromQL expression, for duration, labels and annotations are recreated against a Prometheus data source in Grafana. You need read access to the rule files, the Prometheus configuration that loads them, and a data source in Grafana that points at the same Prometheus server.

Expression reuse: PromQL usually carries over, but test each expression against the Grafana data source because series and label availability can differ.
Routing moves separately: Alertmanager routes and receivers become Grafana notification policies and contact points, which need their own design.
Recording rules: Confirm how many rules are recording rules before planning, since they serve a different purpose from alert rules.
Evaluation state: Pending and firing state held in Prometheus does not move, so expect a fresh evaluation window after cutover.
Ownership mapping: Record which team owns each rule file so the Grafana folders and permissions follow the same boundaries.

Confirm the current data source types and rule fields that the Grafana Alerting documentation supports before you start translating.

How the parallel run and cutover sequence works

The sequence moves alert rules from Prometheus, Mimir or Loki rulers into Grafana-managed alerting in controlled stages, so each rule group is proven before the source copy is disabled. Each step closes with a check that the overlap is safe.

Inventory rules, tenants and ruler ownership
Export every rule group from each ruler and list the tenant or namespace that owns it, the evaluation interval, the receiver it notifies and the team responsible. For Mimir and Loki, this means reading rules through the ruler API or mimirtool and cortextool, and for Prometheus, reading the rule files loaded at startup. Mark rules that use options Grafana-managed alerting does not convert, such as those needing sequential evaluation semantics or unsupported expressions. The step is done when every source rule has one row in the inventory with a status: convertible, convertible with changes, or keep in source for now.
Select a pilot group of low-risk rules
Choose one tenant or a small rule group whose alerts are informational or cover non-critical services, and whose notifications go to a test or low-impact contact point. Confirm with the owning team which on-call rotations will see duplicate notifications during overlap. The pilot is ready when the owners have agreed in writing who will acknowledge alerts from each copy and when the pilot can be rolled back.
Create Grafana-managed copies and confirm permissions
Recreate the pilot rules in Grafana-managed alerting through the Alerting UI, provisioning files or the API, using the same queries and labels. Assign folders and rule group permissions so only the owning team can edit them, and confirm the service account used for provisioning can write to the target folder. The step closes when each copy shows the same expression results as its source in a side-by-side query check.
Run both rulers side by side with duplicate checks
Keep the source rules enabled and let the Grafana-managed copies evaluate in parallel. Compare firing and resolved events for matching labels over the overlap window. The Grafana high availability notes say alerting needs extra configuration to avoid duplicate notifications when more than one Grafana server runs, so confirm that only one instance sends notifications for each rule, and that external Alertmanagers receive one copy of each alert. The step is done when the team records no unexpected duplicates and the mismatches have explanations.
Verify alert state and silences before disabling sources
Before disabling any source rule, check how pending and firing states carry over, because Grafana-managed rules start with their own state. Recreate active silences and inhibition rules in the Grafana or external Alertmanager routing, then confirm that a test alert matches the same silence in both paths. Record which silences were moved and which expire during the overlap. The step closes when the owning team signs off that no silenced alert will page them after cutover.
Cut over in stages by team or namespace
Move the next group of rules, one team or namespace at a time, repeating the duplicate and state checks for each batch. Disable the source copy only after the Grafana-managed copy has run through a full cycle of its evaluation interval without drift. Keep a written record of which source rules are disabled, the date and the rollback path, which is re-enabling the source group and deleting or pausing the copy. The stage is done when the owning team confirms the notifications are correct.
Decommission the source rulers and confirm evidence
When every group is migrated or deliberately kept in source, disable the remaining ruler rules, remove the ruler configuration, and archive the exported rule files and inventory. Confirm that no source rule still evaluates and that Grafana-managed rules show the expected health in the Alerting UI. Keep the inventory and comparison records as change evidence for auditors or internal reviews. The step is done when the ruler is stopped or reduced to its intended function and the decommission record is filed.

Why sequential evaluation changes alert timing during migration

Grafana-managed rule groups evaluate their rules one after another, not in parallel. Each group shares a single evaluation interval, so every rule in the group waits for the rules before it to finish. When a Prometheus or Mimir rule file is imported, its groups keep their names and intervals, but the time a full pass takes can grow with the number of rules and the cost of each query. A group that finished comfortably inside its interval on the source ruler may run later on Grafana-managed alerting, because the data source is queried through Grafana and the rules no longer share the ruler's evaluation loop. The effect is easy to miss because the rules still load and fire, just a little later than before.

The timing risk concentrates in three places. Long-running queries, such as wide range selectors or joins across many series, push back every rule that follows them in the same group, so an alert near the end of the group can fire well after its neighbors. Evaluation intervals become a planning constraint: if a pass takes longer than the interval, the next evaluation is delayed rather than overlapped, which stretches the gap between checks for every rule in the group. Timing-sensitive alerts, such as those with short for durations or rules that guard a paging threshold, are the ones most likely to change behavior silently. Where a rule must fire within a known window, the reader should decide whether to split it into its own group, shorten its query, or accept the new latency in writing.

Measure this in the pilot before any cutover date is set. Run the imported groups side by side with the source rules, then compare the evaluation duration and the time between each rule's expected and actual firing for at least one full business cycle, including peak query load. Ask the team to confirm the evaluation and query metrics that Grafana exposes for their instance, and check the evaluation timing for each group against its interval. Record any group whose pass approaches its interval, because that group will fall behind as more rules are added. Only after the pilot shows acceptable latency for the timing-sensitive rules should the cutover plan treat the Grafana-managed evaluation as the source of truth.

What drives the effort in an alert rule migration

Most of the effort in moving alert rules from Prometheus, Mimir or Loki into Grafana-managed alerting comes from the rule set itself and from the people and routes around it. The cards below separate the one-time conversion and testing work from the costs that continue for as long as two alerting systems run side by side.

Rule and group volume

The number of rules, rule groups and their evaluation intervals sets the size of the conversion and the test matrix. Each group evaluates its rules in sequence, so a group with many slow queries can delay later rules and needs a timing check after import. Count the rules per source (Prometheus, Mimir tenant, Loki ruler tenant) before estimating, and ask any partner to quote per group, not per file. This is a one-time cost, but it grows with every rule that teams keep adding during the migration window.

Unsupported and rewritten options

Some options in source rule files do not carry over unchanged, and others need rewriting to fit Grafana-managed rules. Each one needs a decision: rewrite, drop with a documented reason, or keep the source-managed rule running. Keep a register of these items with an owner for each. Converting the rules is a one-time task, but the register is what lets the risk owner accept gaps in writing.

Notification routing and contact points

Source-managed rules often point at an Alertmanager with its own routes, receivers and silences. Those routes must be rebuilt as notification policies, contact points and mute timings in Grafana. Rework is one-time, but every change to a route after cutover must be made in the new place and reconciled with the old one until the old one is retired. Test each route with a real notification to a non-production channel, and confirm the duplicate suppression setup for any high availability deployment.

Folder, permission and team mapping

Grafana-managed rules live in folders with their own access rules, while source-managed rules follow the tenant or namespace of the data source. Map each team's rules to a folder and confirm who can edit, silence and view them before the first import. This mapping is one-time work for the initial set, then becomes an ongoing governance task each time a team or tenant changes. Ask the implementer to document the mapping as a reviewable table.

Query and data source changes

If rule queries move to a different data source, such as Mimir or Loki exposed as a Grafana data source, the expressions, label names and tenant headers may need adjustment and retesting. A query that returns results in one source can behave differently in another. Re-running each rule against historical data and comparing firing behavior is a one-time test effort. The data source configuration and its credentials then need to be maintained like any other production connection.

Parallel run length

Running the old and new alerting paths side by side is the main recurring cost. Both systems evaluate rules, send notifications and need monitoring, so each extra week of overlap adds operating time and the risk of confusing duplicate alerts. The risk owner should set the length of the parallel run and the exit criteria in writing, such as agreed comparison results per group. Ask for the parallel run length and its exit criteria in any quote, and add the cost of keeping rule-as-code in sync until the old source is retired.

Questions buyers ask before moving alert rules to Grafana

What does it cost to move Prometheus, Mimir and Loki alert rules into Grafana?

The cost is set by the written scope, not by a list price, and DeployOpen does not publish one. The main components are the discovery work (inventorying rules across Prometheus, Mimir rulers and Loki rulers), the conversion and testing of each rule group, the design of notification routing and contact points, the parallel run, and the handover. Ask for the quote to split one-time work from recurring costs, and to state how many rule groups, tenants and rule sources are in scope. Recurring costs follow the infrastructure you choose: Grafana Cloud pricing is published on the Grafana pricing page, which lists a Pro tier with a 19 US dollar monthly platform fee plus usage, while self-hosted Grafana carries your own compute and database costs. The Prometheus project itself is Apache-2.0 licensed, so there is no license fee for the source rules.

How long does an alert rule migration take?

Duration depends on how many rules, rule groups, tenants and notification paths you have, how many of them use options Grafana-managed alerting handles differently, and how long you need to run both systems side by side. Teams with a small, well-documented rule set can cut over quickly, while organizations with many tenants and shared routing trees usually spend most of the time on routing decisions and validation. Ask for a timeline in the written scope that names each phase: inventory, conversion, testing, parallel run and cutover. Confirm the parallel-run length with your on-call and compliance owners before accepting a date.

What must our team provide before the work starts?

The team needs to supply enough material to convert rules without guessing. The usual inputs are:

Exports of the rule groups from each Prometheus, Mimir ruler or Loki ruler, collected with mimirtool or cortextool where applicable
A named owner for each rule group and each notification receiver
A routing map that shows which alerts reach which teams, channels and escalation paths
Read access to the rulers and the Alertmanager configuration, plus a test environment where rules can fire safely

Missing owners are the most common cause of delay, because nobody can approve a converted rule that they do not recognize.

Can our in-house team migrate alert rules without a partner?

Yes, a capable in-house team can do this, especially when the rule set is small and the team already runs Grafana and the source rulers. The work that most often needs outside time is the mapping of options that do not carry over directly, the design of routing across Grafana contact points and external Alertmanagers, and the verification that alerts still fire to the right people. Ask yourself whether the people who own the rules can also run a parallel period without pulling engineers off other work. A fixed-scope partner engagement can cover the same steps with written deliverables, and the choice comes down to available capacity and how much evidence your auditors will expect.

How are permissions and folders mapped to Grafana-managed rules?

Grafana-managed rules live in folders, and folders carry the access model, so the existing tenant or team boundaries must be translated into folder structure and folder permissions before conversion. Each source tenant or namespace usually maps to a folder, and each folder's permissions should match the team that owns the rules. Check whether your current identity setup gives those teams the roles they need in Grafana, because the authentication and access options differ between the open-source edition and Grafana Enterprise. The Grafana authentication docs list which identity providers each edition supports. Write the mapping down as part of the scope, and test it with one user from each team before cutover.

What happens to firing alerts and silences during cutover?

Firing alerts and silences do not move automatically with the rule definitions, so each one needs a deliberate decision. Grafana-managed rules evaluate their own state, which means a rule that is already firing in the source system can appear as a new alert after conversion, and the same notification can reach people twice while both systems run. Plan silences for the cutover window in both places, and record which team confirms each active alert before the old rule is disabled. Once the parallel run ends, disable the source rules in the same change window, and keep the source configuration available for rollback. Confirm the exact behavior with your Alertmanager and Grafana versions in a test environment first.

Do I need to keep Prometheus or Mimir running after the move?

It depends on what the source still does. Prometheus stores metrics in a local time series database and, according to the Prometheus storage docs, local storage is not clustered or replicated, so most teams keep Prometheus for collection even after moving rules. Mimir is a long-term storage and query system, and its rulers can be retired only after every rule group has a working Grafana-managed equivalent. Decide which components keep running, which only stop evaluating rules, and who is responsible for each after cutover, and write that decision into the handover.

What usually goes wrong when alert rules move and how to prevent it

Moving alert rules changes who evaluates them, when they run, how notifications are routed and who can see them. Most failures come from assuming the old and new systems behave the same way, so each risk below has a check to run before cutover.

Duplicate or missing notifications during overlap

While the Prometheus, Mimir or Loki ruler and Grafana-managed rules both run, the same condition can page twice, or a rule can be disabled on one side before the other is confirmed. Grafana's high availability guidance also notes that alerting needs extra configuration to avoid duplicate notifications. Before cutover, decide which system owns notifications for each rule group, record that decision, and compare firing history in both systems for a agreed window.

Silent rules after a permissions change

Imported rules land in folders with their own access settings, and a rule whose folder or data source is not visible to the evaluating identity can stop producing results without an obvious error. Teams that moved rules across folders often find alerts that look healthy but never fire. Prevention: review folder permissions and data source access for each imported group, then trigger a test alert on a known condition and confirm it reaches the contact point.

Unsupported options discovered late

Some options in a source rule file may not map cleanly to Grafana-managed rules, and the gap often appears only when the import fails or a field is dropped. Run the conversion against a copy of every rule file, list each rule that was skipped or changed, and get the owner of each one to sign off on the replacement. Confirm the exact supported fields with the Grafana Alerting documentation for your version, not from memory.

Timing changes from sequential evaluation

Grafana-managed rules within a rule group are evaluated one after another, so a group with many or slow queries can run later than the same rules did in the source ruler. A rule that depends on a timing window, such as a for duration or a comparison against a recent sample, can change behavior even when the query is identical. Measure evaluation duration per group in the new system, and adjust group intervals or split large groups before retiring the old rules.

Routing trees that were implicit

In an Alertmanager setup, routing often lives in a route tree that teams never wrote down, with matchers, group_by settings, inhibition rules and silences doing real work. When rules move to Grafana-managed alerting, those implicit paths disappear unless they are rebuilt as notification policies and contact points. Export the current Alertmanager configuration, map each route and inhibition to a Grafana notification policy, and test representative alerts through every path.

Retiring the old ruler before sign-off

Teams sometimes delete the Prometheus, Mimir or Loki rule files as soon as the import succeeds, which removes the fallback if a rule behaves differently under load. Keep the source rules in version control and disabled, not deleted, until on-call and rule owners have signed off on a defined period of side-by-side results. Document who approves the retirement and what evidence they reviewed.

How DeployOpen scopes and delivers a Grafana alert rule migration

DeployOpen treats moving Prometheus, Mimir and Loki alert rules into Grafana-managed alerting as a scoped engineering change, not a copy job. We inventory the rules, decide which ones convert, test them against your own data sources and hand over documented cutover steps inside infrastructure you control.

How we scope

Inventory every ruler and data source rule group, including which Mimir, Loki and Prometheus rules feed each team.
Record the unsupported options and evaluation behavior that affect each rule before any conversion starts.
Agree the scope, deliverables and timeline in writing, as most engagements are fixed-scope, before work begins.

How we build

Convert rules with the Alerting UI, mimirtool or cortextool as the inventory dictates, and keep the source files under version control.
Rewrite rules that depend on sequential evaluation, then test each one against historical data in your environment.
Set folder permissions, contact points and notification policies so the new rules notify the same people as the old ones.

How we hand over

Deliver a rule-by-rule mapping showing source, converted rule, owner and verification result for each alert.
Document the side-by-side cutover plan, including which system pages on each alert and when the old rules are disabled.
Provide runbooks for rollback and for running both rule sets during the cutover window.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the migration is complete.
Review rule changes and Grafana minor releases on a schedule agreed in the written scope.
Confirm with your team which alert owners, change approvals and audit evidence you need before the retainer starts.

Import Prometheus, Mimir and Loki alert rules into Grafana-managed alerting