Cost Anomaly Alerts: Issues When Log Volume, Retries or Tokens Jump

Last verified on Nov 10, 2026.

Money leaves through behavior before it shows on an invoice. A deploy adds a noisy line. A job retries forever. A field starts carrying a unique value per request. A prompt grows. The Sazabi agent sets up sensors for your project, and four of them watch these behaviors directly in your logs.

The four live signals

• Log volume spike. A deploy suddenly gets very noisy. One debug line that now fires for every request is the classic case.
• Cardinality jump. A field suddenly has far more distinct values, such as thousands of new cache keys a minute.
• Retry storm. The same operation retried in tight loops, such as one job retried many times for each record.
• LLM spend spike. Token usage jumps by feature or customer. It also feeds agent misbehavior.

The agent writes, backtests and maintains these sensors from the fields and jobs in your own logs.

Example: a debug line left in

This is an example, not output from a real project. The service name is made up. A release of catalog-api ships with a debug statement inside the product-lookup path:

2026-11-08T13:30:02Z DEBUG catalog-api lookup sku=A-10492 cache=miss region=us-east source=primary
2026-11-08T13:30:02Z DEBUG catalog-api lookup sku=A-10492 cache=hit  region=us-east source=replica
2026-11-08T13:30:02Z DEBUG catalog-api lookup sku=B-20871 cache=miss region=us-east source=primary

The log volume sensor sees this project logging far above its usual volume. It fires. The agent investigates and finds the release where the volume began and the line responsible.

The issue could be named "catalog-api log volume jumped after release", medium severity. It tells you the extra lines are almost all one statement. Nobody has to open a billing console to learn this, and the fix is one line of code that you can hand to a coding agent with sazabi issues agent-prompt.

Why not read the bill

A bill arrives late and shows a sum. A sensor sees the cause: this service, this field, this job, this customer. By the time a cloud invoice shows the effect, the behavior it measures has run for days. The tradeoff is scope. These sensors see what your logs show, so spend that does not leave a mark in logs is invisible to them.

How you get told

A detection records a signal and starts an investigation. If the cause is harmless, such as a planned migration, it closes without an issue. If the cause is real, an issue opens, with severity, an optional component and the analysis attached.

Cost issues suit a quiet route. Send the Issue triggered notification to the owning team by component, and keep high severity for the shared channel. Repeats fold into the open issue.

What you need

Logs from the services involved. Retry storms need operations with an identifiable key. Cardinality jumps need fields to compare over time. Token spikes need one line per model call.

What it does not cover

• Cloud provider billing and resource spend. There is no live signal for it.
• Cost that never appears in logs, such as idle instances.
• Fixing the cause. The issue explains it; your team ships the change.

Read the cost anomaly detection guide for the by-hand approach. See also the guides on cardinality jumps and LLM spend spikes, and the glossary on cardinality. For metering, see pricing.