General
Troubleshoot general alert issues.Relational fields do not show up when working with SLOs or Triggers
We do not support relational fields in SLOs, Triggers, or Calculated Fields. To emulate the functionality of relational fields, propagate the data you would like to see on to the spans so you can filter on them. For example, if you have data on a root span that you would like to be available to a child span, propagate that data to the child spans.SLOs
Troubleshoot alert issues related to Service Level Objectives (SLOs).Exhaustion Time Burn Alert
Because an incident can dramatically deplete your SLO budget, an Exhaustion Time burn alert may take a long time to resolve even after addressing the incident and deploying a fix. It takes time for this data to age out and recovery to occur. This means that an Exhaustion Time burn alert will remain in a fired state after triggering. If your budget stabilizes, and then starts burning again without ever going back above zero percent (0%), you will not be alerted a second time.
If this scenario is not ideal, you can do one of the following:
- Configure a Budget Rate Alert: Budget Rate Alerts fire regardless of your current budget.
- Reset your SLO Budget. This will erase past failed events in your SLO window, which may impact your charts.
Anomaly Detection
Troubleshoot issues related to Anomaly Detection.Monitoring status
A service shows as Ineligible
Honeycomb bases eligibility on a rolling data coverage window. A service that recently changed traffic patterns, or that sends data intermittently, can drop below the coverage Honeycomb needs for a reliable baseline. Monitoring resumes automatically once the service’s data coverage recovers; you don’t need to re-enable it. To check why a service is ineligible:- Select Anomalies () from the navigation menu.
- Select the service.
- Review the coverage stat next to the service’s status, which shows its current data coverage against the threshold Honeycomb requires.
A service stays in Onboarding longer than expected
Onboarding reflects how much historical data Honeycomb has accumulated for the service so far. A service with sparse or irregular data takes longer to build a reliable baseline than one with continuous traffic. To check a service’s onboarding progress:- Select Anomalies () from the navigation menu.
- Select the service.
- Select the Error Rate or Presence view to explore its current state and how much data Honeycomb has collected so far.
Anomaly Detection flags a normal, expected traffic pattern
The baseline assumes relatively stable traffic. A service with a strong daily or weekly cycle, such as a predictable weekday spike or weekend drop, can trigger false positives, since the current algorithm doesn’t yet model seasonality. To reduce false positives until seasonality support ships, lower the service’s sensitivity threshold:- Select Anomalies () from the navigation menu.
- Select the service.
- Select the Error Rate view.
- Select the sensitivity dropdown and choose Low.
- Select Save.
Notifications
I am not getting notified about an anomaly
On the service’s detail page, check that:- The signal is enabled
- At least one recipient is configured
- The recipient isn’t muted
A signal didn’t resume monitoring after a service became eligible again
Honeycomb preserves your on/off intent for each signal. If you turned a signal off before the service became ineligible, Honeycomb keeps it off rather than resuming it automatically. To resume monitoring:- Select Anomalies () from the navigation menu.
- Select the service.
- Locate the Enable toggle and turn monitoring back on.