When we built the Grafana Alerting integration for ObsrvHQ, the goal was not to replace Grafana. Anyone already running Grafana for dashboards and alerts has invested real time in organizing panels, writing PromQL, and setting up notification policies. The last thing they want is a second system demanding they re-enter all of that information from scratch.
The integration we landed reads your Grafana Alerting rule definitions and builds baselines from the metrics those rules are already watching. By the time your first real page would have fired, ObsrvHQ has already seen several days of behavior and knows what your services look like at 3am on a Tuesday versus 2pm on a Thursday.
This post walks through the four steps to get connected, and explains the design decisions behind each one.
What the integration does (and does not do)
Before the steps: a clear scope boundary. ObsrvHQ does not manage your Grafana alert rules. You keep writing and modifying rules in Grafana's UI. You keep your existing notification policies and contact points. ObsrvHQ sits upstream of the notification dispatch layer. When Grafana evaluates a rule and would normally route a notification, the ObsrvHQ suppression layer checks whether that signal is consistent with baseline before the page goes out.
This is not about intercepting webhooks after the fact. The integration works at the evaluation stage, which means the suppression decision happens with full metric context, not just the alert payload.
We're not saying Grafana Alerting has a quality problem. The quality of your alert rule definitions is entirely yours to manage. What we're saying is that even a well-written threshold rule fires noise when the underlying service's load pattern shifts in ways you didn't anticipate when you wrote the rule six months ago.
Step 1: Generate an API token in Grafana
The integration uses a read-only service account token. In Grafana 9.1 and later, service accounts replace API keys as the recommended approach.
Create a service account with the Viewer role. The integration only needs read access to alert rules and datasource queries. It does not write back to Grafana, modify rules, or alter notification policies. Once you have the service account, generate a token and copy it. You'll paste it into ObsrvHQ in step 3.
One thing worth noting: if your Grafana instance is behind a VPN or only accessible from a private network, you'll need to configure ObsrvHQ's egress IP range in your firewall allowlist before proceeding. The docs page for this integration lists the current CIDR blocks.
Step 2: Identify the datasources ObsrvHQ should learn from
Grafana Alerting rules point at specific datasources. A rule might query Prometheus, another might query a cloud metrics API. ObsrvHQ needs to know which datasources to pull history from when building baselines.
In practice, most teams have one or two primary datasources that cover 90% of their alert rules: usually Prometheus or a hosted equivalent like Grafana Cloud Metrics. For the initial setup, we recommend starting with just those primary datasources. You can add secondary ones later without restarting the learning period.
The reason this matters: baseline learning is per-metric, per-datasource. A latency metric from Prometheus and a latency metric from a cloud provider's API are treated as separate series even if they nominally measure the same thing. Scoping to your primary datasource first means your baselines are coherent and well-sampled before you introduce complexity.
Step 3: Connect in ObsrvHQ's integration panel
In ObsrvHQ, go to Integrations, select Grafana Alerting, and paste your Grafana URL plus the service account token from step 1. You'll select the datasources you identified in step 2 from a dropdown that gets populated by querying your Grafana instance's datasource list.
The connection check runs immediately. If it succeeds, ObsrvHQ starts pulling alert rule definitions and metric query structures. If it fails, the error message will tell you whether the problem is network reachability, token permissions, or a datasource configuration mismatch.
Once connected, you'll see a list of all your Grafana alert rules in ObsrvHQ's rule browser. Each rule shows its query, its evaluation interval, and the current suppression mode (learning, active, or paused). During the initial learning window, all rules are in passthrough mode: ObsrvHQ observes but does not suppress. Pages still fire exactly as they would without the integration.
Step 4: Set the learning window and review suppression candidates
The learning window defaults to 7 days for rules that have stable, predictable patterns and up to 14 days for rules showing high week-over-week variance. You can override these per-rule if you want to accelerate or delay activation for specific alert groups.
At the end of the learning window, ObsrvHQ shows you a suppression candidate report. This is a list of alert rules where it found consistent noise patterns: rules that fired during periods where the metric returned to baseline within the same evaluation window, rules with high fire rate but low acknowledgment rate in PagerDuty or your existing escalation tool, and rules whose firing correlated with known deployment windows.
You review this list and confirm which suppressions to activate. We built this review step deliberately. Automation that suppresses pages without a human reviewing the first batch creates a blind spot, and blind spots are worse than noise. You can approve suppressions individually, by rule group, or all at once if you're comfortable with the signal.
What happens after activation
Once suppression is active, you'll see two things in the ObsrvHQ dashboard: the suppressed page count per rule, and the baseline drift indicator. The drift indicator shows when a metric's behavior has moved enough that the current baseline may no longer be accurate. When drift is detected, the suppression for that rule automatically moves back into learning mode for 48 hours before re-activating.
This is the piece that most static suppression tools miss. A post-deploy traffic pattern looks like noise until it becomes the new normal. ObsrvHQ's baseline relearning handles this automatically, which means you don't have to remember to update suppression rules every time you ship a significant change.
Teams we've worked with during early access typically see the suppression active for their most noise-heavy alert rules within two weeks of connecting. The integration setup itself takes about 20 minutes for a standard Grafana instance. The 7-day learning window is the real time cost, and it runs without any active maintenance from your side.
If you're already on Grafana and want to try the integration, the quickstart is in our docs. We're also happy to walk through your specific alert rule structure on a call if you're uncertain about datasource scoping or suppression mode configuration.