Baseline learning built for dynamic microservice environments
Static thresholds fire on every 9am traffic spike that has been happening every Monday for six months. ObsrvHQ builds a separate envelope for each metric series and suppresses anything that falls inside the learned range, updating continuously as your workload patterns shift.
One envelope per series. Not one threshold per service.
ObsrvHQ builds separate per-weekday, per-hour baselines for every metric series it observes. If api-gateway.cpu_usage runs at 75% every weekday morning, that is the expected value at 9:05am, not an incident. The envelope knows the difference.
Accuracy improves with time. At 48h, initial suppression starts with conservative bounds. At 7 days, full weekday patterns are visible and envelopes tighten. At 30 days, monthly traffic cycles are factored in. You do not configure any of this.
- + Tracks intraday seasonal patterns automatically, no rule authoring needed
- + Widens automatically 15 min post-deploy, then tightens back
- + Per time-series scope: 1,000 metric series means 1,000 independent envelopes
One incident. Not twelve alerts.
A database connection pool exhaustion typically shows up as simultaneous anomalies in latency, error rate, and queue depth across multiple downstream services. That is one incident. Without correlation, it becomes twelve separate pages in your PagerDuty escalation policy.
ObsrvHQ groups metric anomalies that co-occur within the same time window into a single correlated incident signal. The correlation decision happens before anything reaches your alertmanager, so the grouping is reflected in what you actually get paged for, not discovered after the fact in a post-mortem.
The post-deploy alert storm, stopped before it starts
Every production deploy triggers a 5-15 minute period of elevated metrics: connection pool churn, cache invalidation, latency spikes as new instances warm up. None of those require a page. All of them will fire your static threshold rules.
Post a deployment event to ObsrvHQ via webhook or the API. It widens the baseline envelope for a configurable window, then returns to normal sensitivity automatically. Your CI/CD pipeline adds one curl call. Your on-call rotation stops getting woken up for deploys.
event: deployment service: checkout-api version: v2.14.3 environment: production suppress_window_min: 15 widen_multiplier: 2.0 # ObsrvHQ widens envelopes for 15 min # then auto-tightens back to baseline
Programmatic access when YAML rules are not enough
The YAML rule schema handles most suppression configuration. For teams that want to go further: fetch baseline envelope data for any series, build suppression rules in code, or pipe decision history into your SIEM for audit logging and compliance workflows.
ObsrvHQ is not a black box. The dashboard and the API use the same endpoints. Everything the UI shows you is also available programmatically, including per-hour envelope bounds, sensitivity settings, and the exact reason each alert was suppressed or paged.
curl -H "Authorization: Bearer $TOKEN" \ "https://api.obsrvhq.com/v1/baselines ?service=checkout-api &metric=error_rate &window=7d" # Returns: envelope min/max per hour, # recent decision history, sensitivity # settings for the series
Connect once. Let baselines build. Stop babysitting thresholds.
Free tier: 500 metric series monitored, no credit card required. First suppression decisions arrive within 48 hours.