Skip to main content

Overview

Anomaly detection watches your AI traffic continuously and alerts you when something deviates from normal. Cost spikes, latency degradation, elevated error rates — Lectr surfaces them automatically so you don’t have to watch a dashboard all day.
Your costs spiked 4.4x above their 7-day baseline at 3pm yesterday.
Feature: chat  |  Detected: Mar 14, 15:02

How it works

Lectr builds a rolling 7-day baseline for each org and feature. Every 5 minutes, it compares current metrics against that baseline. When something deviates by more than 2 standard deviations, an anomaly is recorded and an alert is sent.
Build baseline (7-day rolling window)

Compare current metrics every 5 minutes

Deviation > 2σ → record anomaly → send alert
Baseline requirements: Anomaly detection activates automatically after 48 hours of traffic. Before that, the dashboard shows:
⏳ Building baseline — anomaly detection active in ~X hours
No configuration required. It starts watching as soon as you have enough data.

What Lectr detects

Anomaly typeWhat it means
Cost spikeSpend for an org or feature is significantly above its baseline
Latency degradationP95 latency has increased significantly vs baseline
Error rate spikeError rate is elevated above normal levels
Traffic anomalyRequest volume is unusually high or low
Model driftmodel_actual is diverging from model_requested unexpectedly
Each anomaly includes:
  • The anomaly type
  • Which feature it affects (if feature-tagged)
  • The baseline value vs the observed value
  • How many standard deviations above baseline
  • When it was detected

Alerts

When an anomaly is detected you receive:
  • An in-dashboard notification — visible in the anomaly feed immediately
  • An email alert — sent once per anomaly, not once per continued spike
The email fires once when the anomaly is first detected. If the spike continues, you won’t be flooded with repeat emails — just the one alert until it’s dismissed.
Email alerts require a verified email address on your account. Alerts are sent to all Auth0-authenticated members of the org.

The anomaly feed

The dashboard shows a chronological feed of detected anomalies with severity indicators. Anomaly markers also appear on your time-series charts — vertical indicators at the point where the anomaly was detected. Each anomaly in the feed shows:
⚠️  Cost spike — feature: chat
    4.4x above 7-day baseline ($0.42 → $1.87 per request)
    Detected Mar 14 at 15:02
    [Dismiss]

Dismissing anomalies

If an anomaly was expected — a deliberate traffic spike, a planned test run, a known provider issue — you can dismiss it. Dismissed anomalies:
  • Are removed from the active anomaly feed
  • Do not trigger repeat alerts
  • Are excluded from future baseline recalculation
  • Remain visible in the anomaly history
Dismissing tells Lectr “this was intentional” — it won’t keep alerting on the same event and won’t let it skew your baseline going forward.

Degradation indicator

If the anomaly detection pipeline itself falls behind — the event worker is overloaded or the database is unavailable — the dashboard shows:
⚠️ Observability degraded — data may be incomplete
Anomaly detection runs on the cold path. It never affects your proxy or request performance. If detection is degraded, your requests continue uninterrupted.

Feature tagging and anomaly detection

Anomaly detection works at two levels:
  • Org level — aggregate metrics across all traffic
  • Feature level — per-feature metrics when X-Lectr-Feature is present
Without feature tagging, you’ll know something spiked but not which feature caused it. With feature tagging, the anomaly feed tells you exactly:
Without tagging:  Cost spike detected for your org
With tagging:     Cost spike detected for feature "chat"
See Feature Tagging to add feature-level visibility.

What anomaly detection is not

Anomaly detection is observational — it tells you what happened, not why. It does not automatically take action on your traffic. Automated responses to anomalies — switching models, enforcing budgets, triggering fallbacks — are coming in Phase 3.2.

Reference

Baseline window7 days rolling
Check frequencyEvery 5 minutes
Detection threshold2 standard deviations from baseline
Minimum data48 hours before detection activates
Minimum sample100 requests per group for meaningful baseline
Alert frequencyOnce per anomaly — no repeat emails
Runs onCold path — zero hot path impact

FAQ

You need at least 48 hours of traffic before Lectr has enough data to build a meaningful baseline. The dashboard shows a countdown. If you’ve had traffic for longer than 48 hours and detection still isn’t active, check that your X-Lectr-Key header is present on requests so events are being attributed to your org.
Sensitivity adjustment is not available yet — the 2 standard deviation threshold is fixed. If you’re seeing false positives, dismiss them. Dismissed anomalies are excluded from baseline recalculation which helps Lectr learn what’s normal for your traffic over time.
Gradual increases are harder to detect with a deviation-based approach — if costs creep up slowly over weeks, the baseline moves with them. Anomaly detection is best at catching sudden, unexpected changes. For gradual trends, use the cost trend charts in the dashboard which show period-over-period comparisons.
No. Detection runs on the cold path every 5 minutes against stored event data. It has zero impact on request performance.
A new feature tag starts with no baseline. Detection for that specific feature activates after 48 hours of tagged traffic. Org-level detection continues unaffected.
Not yet — email and in-dashboard notifications only for now. Slack and webhook integrations are on the roadmap.