Event Volume Anomaly Detection: Issues When a Rate Jumps or Drops

Last verified on Nov 10, 2026.

What it catches

An event that happens a hundred times an hour is a heartbeat. When the heartbeat doubles or falls by half, something changed, even if no line says "error".

Volume shift watches the rate of individual events in your logs and notices when one moves far from its usual rate. It is not about total log volume. A pipeline that logs more overall can hide one event going to zero, and the reverse is just as true, so the question is asked per event.

Real situations it points at:

• A client library bug starts calling an endpoint in a loop.
• A signup form is broken on one path and registrations fall.
• A scheduled blast sends mail twice because two workers ran it.
• A cache misconfiguration turns every read into a database call and the call event multiplies.
• A bot finds an unauthenticated route and the hit count climbs.

Example: reset emails at six times normal

This is an example, not output from a real project. Your accounts-api service logs each password reset email it queues. On a typical Tuesday afternoon you see a handful per minute:

2026-11-08T15:20:11Z INFO accounts-api password_reset_email_queued user=u_3021 variant=reset_v2
2026-11-08T15:20:11Z INFO accounts-api password_reset_email_queued user=u_3021 variant=reset_v2
2026-11-08T15:20:12Z INFO accounts-api password_reset_email_queued user=u_3021 variant=reset_v2
2026-11-08T15:20:12Z INFO accounts-api password_reset_email_queued user=u_3021 variant=reset_v2

The same user ID repeats within a second. The event rate is several times the usual Tuesday level. Sazabi opens an issue. An example of the contents:

• Name: Password reset emails queued far above usual in accounts-api
• Description: The reset-email event is running several times above its usual rate for this hour. The repeated user ID suggests one request is queuing the email more than once.
• Severity: medium

Whoever receives it sees that the rate is the problem and that a repeated user is the likely mechanism, rather than starting from a dashboard graph.

How Sazabi sets it up

You set nothing up. The Sazabi agent sets up sensors for your project and maintains them over time. Sensors are standing questions about your logs, and this one asks: "Is any event running far above or below its usual rate?"

Regular rhythms, such as a Monday morning rush or a quiet Sunday night, are part of an event's normal pattern and do not count as a shift. Each event is judged on its own, so one event moving does not hide behind steady totals, and the issue names the event that moved.

When it fires, Sazabi records a signal and the agent investigates. The investigation looks at the event, its neighbors and what else changed, then opens an issue when the problem is real.

What you see and how you get told

The issue shows the event, the direction of the shift and the agent's explanation. From the thread you can ask what else changed at the same moment, hand the fix to a coding agent or mute the issue if the traffic is expected. An Issue triggered notification lands in your in-app feed, and delivery rules can send high-severity issues to a shared Slack or Microsoft Teams channel. sazabi signals list --type sensor shows the firings behind them.

What you need

Production logs with stable event lines, ideally structured. See structured logging for why consistent fields help. Sources like OpenTelemetry, AWS and Cloudflare all work.

What it does not cover

• A rate that changes slowly across weeks. That is drift, not a shift.
• Events too rare for a rate to mean anything.
• A change inside the content of events, such as new nulls. That belongs to field drift.
• Latency. Separate sensors handle response times.

A line that stops entirely is the special case covered by vanished events. Issues are metered; see pricing.