Cardinality Jump Alerts: An Issue When a Field Suddenly Has Far More Values

Last verified on Nov 10, 2026.

What it catches

Some fields are supposed to take a small set of values: a region, a plan, an HTTP method. Others are supposed to take many: a user ID, an order number. A cardinality jump is when a field of either kind suddenly takes far more distinct values than it did before.

That is rarely a number you would think to chart. It shows up as a bill, a full cache or a slow database after the fact. Cardinality jump moves the discovery to the moment the change starts.

What tends to cause it:

• A cache key gains a timestamp or request ID, so nothing is ever reused.
• A URL path with an ID in it gets logged as the route, so every request looks like a new route.
• A client sends random values in a header or query string to evade rate limits.
• A bug writes an unbounded value, such as a full payload, into a field meant for a short label.
• A newly attached tag turns one category into thousands.

Example: the cache key that stopped repeating

This is an example, not output from a real project. A catalog-api service logs cache reads with the key it used. Normally the same few thousand keys repeat all day:

2026-11-08T16:02:10Z INFO catalog-api cache_miss key=product:4412:v3 region=us
2026-11-08T16:02:10Z INFO catalog-api cache_miss key=product:4412:v3:1762617730 region=us
2026-11-08T16:02:11Z INFO catalog-api cache_miss key=product:4412:v3:1762617731 region=us
2026-11-08T16:02:12Z INFO catalog-api cache_miss key=product:4412:v3:1762617732 region=us

A release added a timestamp to the key. Every read is now a miss with a key nobody has seen before. Sazabi opens an issue. An example of the contents:

• Name: Cache keys in catalog-api no longer repeat
• Description: The key field on cache events has far more distinct values than usual. New keys differ only by a trailing epoch timestamp, so they cannot be reused and every read goes to the database.
• Severity: high

The finding includes sample keys and the point where the new shape began. That is usually enough to find the change.

How Sazabi sets it up

You set nothing up. The Sazabi agent sets up sensors for your project and maintains them over time, including for fields in your logs where the count of distinct values is worth watching. In plain words: "Tell me when the number of distinct cache keys per minute goes far above its usual level."

The same field can be judged separately per service or per route, so one service's jump does not hide in the totals. The agent writes, backtests and maintains these sensors.

A detection records a signal and starts an investigation. The investigation decides whether the extra values are a real problem and opens an issue if so.

What you see and how you get told

You see an issue with the field, the shape of the new values and the agent's reading of where they come from. Use the thread for follow-up questions, or run sazabi issues agent-prompt to hand the fix to a coding agent. An Issue triggered notification arrives in your in-app feed, and delivery rules can send the high-severity ones to a shared Slack or Microsoft Teams channel. The raw detections are in sazabi signals list --type sensor.

What you need

Logs that carry the field as its own value. Consistent key names matter more than the format. See the glossary entry on cardinality for the concept, and connect logs through OpenTelemetry or AWS.

What it does not cover

• Metric label sets in a metrics system you run elsewhere.
• Fields your services never log.
• A rate change on an event, which is volume shift.
• Contents that go null or empty, which is field drift.

If you manage the problem by hand, the guide to high cardinality covers the metrics-side background. Issues are metered; see pricing.