Skip to main content
Beta Anomaly Detection watches your services and tells you when something is worth investigating. It builds a statistical baseline of normal behavior for each service, then notifies you when behavior deviates from that baseline, so you can catch problems without predicting a failure mode or setting a threshold in advance.

​
What you can do

With Anomaly Detection, you can:
  • Catch a failure mode you haven’t written a Trigger for, since Anomaly Detection doesn’t require you to predict what could go wrong.
  • Find out when a service stops sending data entirely.
  • Get error rate coverage across many services without hand-configuring a threshold for each one.
  • Hand an anomaly straight to a Canvas investigation, so a likely cause is waiting by the time you look.
For step-by-step investigation guides, visit:

​
How it works

Honeycomb runs a continuous cycle for each monitored service, then surfaces the results through a set of states, an eligibility check, and a sensitivity threshold you control.

​
The detection cycle

For each monitored service, Anomaly Detection runs these steps:
  1. Onboarding: Honeycomb identifies eligible services automatically and enrolls them using their existing historical data. Honeycomb then builds a statistical baseline from that historical data, defining what normal looks like for the service. (Honeycomb will continue to analyze services and signals for eligibility, traffic patterns, and detection, so the baseline adapts as a service’s behavior evolves.)
  2. Aggregate: Honeycomb continuously aggregates the relevant signal in real time.
  3. Detect: Honeycomb compares live values against the baseline and, when a sustained deviation occurs, flags an anomaly and sends a notification.
The baseline assumes relatively stable traffic. Services with strong daily or weekly cycles, such as predictable weekday spikes, can generate false positives until seasonality support ships.

​
Signals

Anomaly Detection currently covers two signals, built on Events data for services:

​
Service states

Each service shows one of the following states, reflecting its current eligibility and monitoring status:

​
Service eligibility

Honeycomb evaluates services against a rolling data coverage window to decide whether detection is likely to produce meaningful results. Ineligible services remain visible in your services list, so you can see your full coverage picture along with the reason a given service isn’t monitored yet.

​
Sensitivity thresholds

Each signal has its own sensitivity control:
  • Error rate: Uses a named sensitivity threshold (high, medium (default), or low).
  • Presence: Uses a time-based threshold, set to five minutes by default, that determines how long a service’s data stream can go quiet before Honeycomb flags it as an anomaly.

​
MCP support

Anomaly Detection service profiles are available through the Honeycomb MCP server, so agents can pull anomaly status alongside service map data. To learn more, visit Service Map and Anomalies.

​
Choosing between Anomaly Detection, Triggers, and BubbleUp

Which tool fits depends on how much you already know about the problem:
  • You already know what could go wrong and want to set a specific threshold: Use a Trigger. Triggers are static: you define the condition, and Honeycomb checks your data against it.
  • You already know something is wrong and need to find why: Use BubbleUp. Select the unusual region of data, and BubbleUp highlights which dimensions differ most from the baseline.
  • You want Honeycomb to tell you what to watch for: Use Anomaly Detection. It learns what normal looks like for a service and alerts you when something changes, with no configuration required.
These tools work together, each covering a different stage of the same investigation. When Anomaly Detection surfaces an anomaly, it can automatically start a Canvas investigation that surfaces a likely cause, so diagnosis is already underway by the time you look. To learn how to set up auto-investigation, visit Auto-investigate Anomalies.

​
Next steps