Detectors

They are not all equally mature

Read this list as a range, not a uniform set. Some detectors have years of production traffic behind their thresholds; others are new, and we ship those deliberately handicapped rather than confident. A new detector is born capped at warning severity — it emits at most a warning, and that ceiling is pinned, so repeated firing cannot ratchet it up to critical the way an uncapped alert would. It stays capped until it has run long enough against real traffic for us to trust it. Today Infrastructure Metric Rules, Host Liveness and Capacity Forecast are capped this way. The practical effect: they will inform you, but they will not wake you up. Newness is not the only reason a detector holds at warning — Outlier Detection is capped permanently and by design, because a multi-dimensional outlier is a lead worth reading rather than a conclusion worth paging on. So read the cap as a statement about confidence, not about age.

Several detectors also stay quiet at first by design. Anything that scores a value against a seasonal baseline needs to observe your normal before it can call something abnormal, so it spends its learning window building that baseline silently instead of firing on your first day. Detectors that need no baseline — a new error message, a service going silent — are useful within the hour.

What you do not need: a search query, a threshold, or a dashboard to hang the alert off. Detectors read the telemetry you already send. If you do want a condition of your own on top of these, that is the User-Defined pair below — Threshold Rules and Composite Rules.

Statistical

9 detectors

• Volume Anomaly

  Detects spikes, drops, and flatlines in log volume vs daily and weekly baselines per service.

• Silence Detection

  Catches services that stop logging when they normally log every N seconds. The most dangerous failure mode: no errors, just absence.

• Outlier Detection

  Multi-dimensional outliers in log feature space. Catches subtle anomalies that single-axis thresholds miss.

• Numeric Field Anomaly

  Discovers the numeric fields your logs carry — payment amounts, cache hit rates, queue depths, inference scores — and flags when one drifts from its baseline.

• Post-Change Regression

  Checks whether a deploy, config change or scale event actually made things worse, by comparing the window after the change against the matched window before it — per service.

• Error Growth Forecast

  Spots an error signature whose arrival rate is climbing and projects when it reaches a volume that matters — as a time range, before the incident, not after.

• Error Rate Anomaly

  Per-service error percentage anomalies vs baseline, with sustained-elevation guards so a single noisy minute doesn't fire and slow ramps still get caught.

• Recurring Pattern Detection

  Identifies log patterns that recur on a schedule — daily batch jobs, hourly cron runs, weekly reports — and flags when one fails to fire on its expected cadence.

• Cost Anomaly

  Catches whole-tenant log-volume spikes that translate into surprise observability bills — before the invoice does.

Error Intelligence

2 detectors

• New Error Detection

  Catches errors that have never appeared in your 7-day baseline. On connect, the baseline seeds from your last 7 days of historical logs — push history for day-1 alerts, or wait a week for organic warm-up.

• Pattern Clustering

  Groups errors with similar templates so many variants of the same problem cluster into one alert. Surfaces brand-new clusters as they appear.

Domain-Specific

9 detectors

• Kubernetes Detection

  70+ rules for OOMKilled, CrashLoopBackOff, ImagePullBackOff, FailedScheduling, evictions, probe failures, and other Kubernetes failure modes.

• AWS Service Detection

  Patterns for RDS, S3, DynamoDB, ECS, EKS, IAM, KMS, Lambda, and 20+ other AWS services. Catches throttling, capacity events, IAM denials, and service-specific failure modes.

• Serverless Detection

  Lambda timeouts, cold starts, throttling, init failures, runtime crashes, and concurrency limits across functions.

• Database Detection

  Connection pool exhaustion, deadlocks, slow queries, replication lag, schema migration errors, and transaction aborts across Postgres, MySQL, and MongoDB.

• Dependency Detection

  Upstream service failures, circuit breaker trips, retry exhaustion, and cascading failures between services.

• Web / HTTP Detection

  4xx and 5xx surges, slow endpoints, TLS handshake failures, gateway timeouts, and load balancer health events.

• Security Event Detection

  Brute-force authentication attempts, anomalous auth failures, privilege escalations, and suspicious access patterns from your auth and audit logs.

• Search Detection

  Slow queries, query failures, index issues, and scoring anomalies in Elasticsearch / OpenSearch / Solr.

• Infrastructure Detection

  Disk pressure, memory pressure, CPU steal, swap activity, kernel errors, and other host-level signals from system logs.

Metrics & Infrastructure

7 detectors

• Metric Anomaly

  Spikes and dips in any numeric metric — CPU, memory, queue depth, request rate — against that metric's own seasonal baseline.

• Resource Saturation

  A resource pinned near its limit — CPU, memory, disk, connection pool — long enough to matter, not a momentary touch.

• Slow Drift

  The boiling-frog leak: a metric trending steadily the wrong way over hours, too gradual for any spike alarm to catch.

• Metric Reporting Gap

  A metric series that simply stopped arriving — a dead exporter, a broken scrape, a crashed agent — where the absence is the alert.

• Infrastructure Metric Rules

  Named-metric guardrails: pods stuck Pending, consumer-group lag, replication lag, restart storms — metrics with a known-bad level.

• Host Liveness

  Flags a host or node that has stopped reporting, so a silent box surfaces as a warning rather than as missing data.

• Capacity Forecast

  Projects a filling resource forward and warns with an estimated time-to-full while there is still room to act.

Traces

5 detectors

• Trace Latency Break

  Catches a service whose request latency regressed against its own past — the whole distribution shifted slower.

• Trace Tail Shift

  Catches partial degradation: most requests are fine but a slice falls off a cliff — the tail blows up while the median holds.

• Trace Error Origin

  Walks the span graph to find the origin service of an error cascade — where the failure started, not the services that merely reported it.

• Trace Throughput Drop

  Catches a service whose request volume collapsed — crashed, deadlocked, or off the load balancer — when no slow or error spans give it away.

• Trace New Operation

  Flags a service serving an operation it never served before — an unannounced deploy, a new endpoint, or a client calling a new path.

SLO & Performance

2 detectors

• Golden Signal Monitoring

  Latency, saturation, and per-service error rate. Three of the four SRE golden signals — traffic is covered by Volume Anomaly.

• SLO Monitoring

  Error budget tracking with burn rate prediction. Get warned before the SLO breaches, not after.

User-Defined

2 detectors

• Threshold Rules

  Custom alert conditions on any query, with cooldown and duration guards. Use when you need a hand-tuned alert beside automatic detection.

• Composite Rules

  Multi-condition alert rules combining several signals. Use when no single threshold captures the failure mode.

Next

• Send metrics — turns on the metrics and infrastructure detectors above.
• Send traces — turns on the trace detectors, and derives request rate, error rate and latency per service.
• API reference — list, read and resolve the alerts these detectors produce.
• What we don't do — the limits, stated plainly, before you find them yourself.