Efficiency Issues: Spend That Grew for No Reason and Telemetry That Went Missing

Last verified on Nov 10, 2026.

Two kinds of waste

The efficiency group is for problems that do not break anything on the day they start. A debug line ships in a release and quietly multiplies your log bill. A job retries each record thirty times. A customer's agent loops on a model call. On the other side, a service stops sending logs after a config change, and everyone assumes that no news is good news.

One side is spending more than the work justifies. The other is seeing less than you need. Both cost you, and neither pages anyone. The cost anomaly guide gives vendor-neutral background on the spend side.

Which signals feed the group

You set nothing up. The Sazabi agent sets up sensors for your project and maintains them over time. Six live signals open efficiency issues.

Cost anomaly

• Log volume spike: a deploy suddenly gets very noisy.
• Cardinality jump: a field suddenly has far more distinct values, such as a new ID in every cache key.
• Retry storm: the same operation retried in tight loops.
• LLM spend spike: token use jumps for a feature or a customer.

Observability gap

• Service went quiet: a source stops sending logs.
• Secrets or personal data in logs: tokens, keys or personal details written to logs, which makes the logs a liability.

Example: one line, forty million times

This is an example, not output from a real project. A release adds a debug statement inside a hot loop of the search-indexer service:

2026-11-08T10:15:01Z DEBUG search-indexer scoring candidate id=c_20991 shard=4 score=0.42
2026-11-08T10:15:01Z DEBUG search-indexer scoring candidate id=c_20992 shard=4 score=0.17
2026-11-08T10:15:01Z DEBUG search-indexer scoring candidate id=c_20993 shard=4 score=0.88

Nothing is wrong with the indexer. But total log volume jumps right after the deploy, and one service produces most of it. The sensor asks whether the volume of logs has jumped far above its usual level. The agent investigates, and the issue it opens reads along these lines:

search-indexer log volume jumped after the 10

release (medium, component: search). One debug message accounts for nearly all of the increase. Evidence: volume before and after the deploy, the message text, the release that introduced it.

The fix is a one-line change, and you hear about it on the day of the release, not on the day of the invoice.

How each side is set up

Nobody writes a rule for a jump in log volume or a service that went quiet. Neither needs any vocabulary of yours.

Retry storms, cardinality jumps and LLM spend depend on your operations, fields and models. The agent reads your logs, finds the operation names and fields worth watching, and writes and maintains the sensors. Regular rhythms, such as a Monday morning ramp, are part of the normal pattern and are not a spike.

What you see and how you are told

The firing starts an investigation, and the issue opens only when the problem is real. Each issue carries severity, an optional component and the agent's analysis with evidence. A recurrence of an open issue folds into it.

Issue triggered goes to the app, email, Slack DM, SMS and shared channels under delivery rules. You can route efficiency issues to a cost or platform channel at medium and below, so they do not compete with outages. Resolve, ignore or mute from the dashboard, Slack, Teams or CLI. sazabi issues agent-prompt produces a prompt you can give a coding agent, which suits the debug-line case well.

What it does not cover

• Cloud spend anomalies from a billing export are not covered today.
• Logs that arrive in a format Sazabi cannot read, a general blind spot report and timestamp skew are not covered today.
• Sazabi reads logs, so spend that leaves no trace in them is invisible to it.

Issues detected are metered, so a noisy project also shows up in your Sazabi usage. See pricing. To send logs, start with OpenTelemetry or another integration.