Data Integrity Alerts: Issues When Values, Counts or Freshness Stop Adding Up

Last verified on Nov 10, 2026.

The system is up, the data is wrong

Data problems rarely throw. A deploy starts writing a null where there was always a value. A vendor renames a response field. The ledger and the order table slowly stop agreeing. A cache serves yesterday's directory. Each of those runs for days if nobody asks the right question.

Four signals behind this page

The Sazabi agent reads your logs to find the events, fields and counts that matter, then sets up and maintains sensors that ask about them:

• Stale data. Caches and sync jobs stopped refreshing, so a directory is days old.
• Field drift. Values inside events shift: new categories, nulls, empty strings or unusual sizes.
• Contract change. A vendor's response shape changes, for instance a field your code relies on now arrives empty.
• Reconciliation mismatch. Counts disagree between systems, such as payments captured versus orders created.

Each tenant or field is judged on its own, so one bad group does not hide inside healthy totals.

Example: two counts that should match

This is an example, not output from a real project. The billing-worker service logs a summary every hour, and the orders-api logs each order it creates:

2026-11-08T09:00:00Z INFO billing-worker captured_payments hour=08 count=412
2026-11-08T09:00:00Z INFO orders-api orders_created hour=08 count=396
2026-11-08T10:00:00Z INFO billing-worker captured_payments hour=09 count=388
2026-11-08T10:00:00Z INFO orders-api orders_created hour=09 count=351

Neither service reports an error. Together they say customers were charged for orders that were never created. The question the sensor asks is a comparison, and it allows for normal lag between the two. An example issue:

• Name: Payments captured exceed orders created
• Description: For two hours in a row, payments captured outnumber orders created by a widening margin, which is far outside the usual gap. Order creation is the likely side failing.
• Severity: high

Customers were charged without getting what they paid for, which is why an example like this one rates high.

Seeing and routing it

The issue shows the description, the analysis and the evidence, which here is the two sets of counts. Ask the thread which tenant accounts account for the gap, or hand the fix to a coding agent. Delivery rules can send integrity issues to the team that owns the component, such as billing, and keep the rest of the company out of the loop.

What a good first week looks like

Start with one comparison that would cost you money if it drifted: payments against orders, messages sent against messages delivered, rows exported against rows imported. Make sure both sides log a count. The agent can then write the question and keep it current. After that, add the next comparison. Asking support for a specific sensor in plain words is also an option when you know exactly which two numbers should agree.

What you need to send

• A log line or event for each side of any comparison you care about.
• Fields that are named consistently, so a null on one is visible. The structured logging entry explains the practice.
• For vendor responses, logging the fields your code reads from them.

The sensors never see data you do not log, and they do not connect to your databases.

Not covered today

• Writes that were acknowledged and never stored.
• Work processed twice.
• Data you never log.

Related pages

The vendor-neutral write-ups are the field drift guide, the reconciliation mismatches guide and the stale data guide. See also silent failures and dependency failures. Issues detected are metered, so check pricing.