Back to use cases
Data & Analytics

Anomaly Detection Across Connected Data

Opulent investigates metric drops, compares periods, and correlates events across data sources to find the root cause, with the SQL and charts attached.

MCP
AuthorOpulent
CategoryData & Analytics
FeaturesMCP
start it with one message
Investigate the drop in [metric] from [time A] to [time B]. Pull data from Amplitude, PostHog, Grafana, and Sentry; compare the periods; correlate events across sources; and return the most likely root cause with the SQL, charts, and a confidence level.
Run this in OpulentCopy it, swap the names for your own, and send it.
connected systems
AmplitudeAnalyze product data, experiments, and user behavior
GrafanaQuery observability data, dashboards, and incidents from Grafana
PostHogPerform product analytics, manage feature flags, and run experiments
SentryReview errors, analyze root causes, and suggest fixes for rapid issue resolution
step 1

Connect the sources and write the investigation playbook

Connect Amplitude and PostHog for product analytics, Grafana for observability metrics, and Sentry for error data. Opulent queries each source in parallel and correlates what changed around the anomaly window.

The investigation logic lives in a playbook, a reusable, named set of steps Opulent follows every run. It defines the anomaly detection method, the comparison window, the sources to cross-check, and the output format.

Playbook: !anomaly-investigation

For any metric drop or spike:
1. Define the metric and the anomaly window (e.g., conversion
   rate dropped 20% between 14:00 and 16:00 UTC).
2. Pull the metric time series from the primary source.
3. Compare to the prior period and the prior same-day period to
   rule out seasonality.
4. Query correlated sources: releases, feature flags, errors,
   infrastructure events, marketing spend, support volume.
5. Build a ranked hypothesis list with evidence for and against
   each candidate cause.
6. Return the top hypothesis, confidence level, supporting SQL
   and charts, and the next validation step.
Tip

Keep a 'known good' baseline query saved in the playbook. Comparing an anomaly to the wrong baseline produces false causes; a consistent baseline definition is half the investigation.

step 2

Trigger on alert or on demand

Send the initial prompt when you notice a drop, or connect Grafana alerts to Opulent so an anomaly investigation starts automatically when a threshold breaches.

For product metrics, schedule a daily anomaly scan: Opulent reviews the last 24 hours, flags anything outside a rolling band, and posts a short summary to the team channel.

The sharp edge: correlation is not causation. The playbook must rank hypotheses and state confidence, not declare a cause just because two lines moved at the same time.

step 3

Run one investigation end to end

Take a drop in checkout conversion from 4.2% to 3.1% starting at 14:00 UTC. Opulent pulls the conversion funnel from Amplitude, compares it to the same hour last week, and checks PostHog for feature-flag exposure.

It queries Grafana for infrastructure events and Sentry for error spikes. It finds that a new payment-method rollout started at 13:55 UTC and that users exposed to the new method convert 35% lower; the legacy path is unchanged.

The readout names the feature flag as the top hypothesis, attaches the SQL and funnel charts, and recommends a rollback or an experiment to isolate the issue.

Metric: checkout conversion
Anomaly: 4.2% -> 3.1% starting 14:00 UTC

Run actions:
- Pulled Amplitude funnel: step drop at payment selection.
- Compared to same hour last week and prior week, both higher.
- Checked PostHog feature flags, "new_payment_method" rolled
  out to 50% at 13:55 UTC.
- Checked Grafana: no infra event correlated.
- Checked Sentry: payment errors up 12% on the new method.
- Top hypothesis: new payment method degrades checkout
  (confidence: high).
- Recommendation: roll back to legacy method and run a targeted
  experiment.
step 4

What exists when the run finishes

A real run produces an investigation packet you can act on: the metric time series with the anomaly flagged; comparison charts against the baseline period; a ranked hypothesis list with evidence for and against; the SQL and query links for each source; and a recommended next step with an owner.

The SQL and charts are the proof-of-work: they let anyone re-run the same queries and reach the same conclusion, which makes the readout credible enough to justify a rollback or a fix.

step 5

Sharpen the anomaly practice

When Opulent misses a known cause, add it to the playbook's correlation checklist: 'always check feature-flag rollouts, email sends, and pricing changes.' Write the lesson into memory (the notes a run recalls next time) so the next run checks the same edge.

Build a library of validated root causes as reusable hypotheses, so a recurring anomaly type gets diagnosed faster each time it appears.

The natural chain: once the root cause is found, hand it to the right fix workflow, Auto-Fix Failing CI Builds for a broken deploy, Auto-Investigate Datadog Alerts for an infrastructure issue, or Data Analysis as an Agent-Run Workflow for a deeper business impact assessment.