Reconciliation Mismatch Alerts: An Issue When Two Systems Disagree on Counts

Last verified on Nov 10, 2026.

What it catches

Two systems that should agree on a number rarely fail loudly when they stop. A checkout writes an order, a payment provider captures the money, a fulfillment job ships the box. If one leg drops, every individual log line still looks fine. Only the counts betray it. The Sazabi agent sets up sensors for your project, and Reconciliation mismatch is one of the signals it writes where your logs let it compare two counts. Typical pairs:

• Payments captured against orders created.
• Messages queued against messages delivered.
• Records received from a partner feed against records processed.
• Signups logged by your app against accounts created in the identity provider.

Example: captures outrun orders

This is an example, not output from a real project. Both sides log each event with a counter-friendly message.

2026-11-08T14:00:12Z INFO  payments capture succeeded payment_id=p_7712 amount_cents=4900
2026-11-08T14:00:14Z INFO  orders order created order_id=o_9021 payment_id=p_7712
2026-11-08T14:07:41Z INFO  payments capture succeeded payment_id=p_7733 amount_cents=2900
(no matching "order created" for p_7733)

The sensor asks something like: "Tell me when captured payments are well above orders created." A single missed order does not open an issue, since the two sides always differ a little. A hundred missed orders over the afternoon does.

An example issue:

• Name: Payments captured but no orders created since 14
  UTC
• Description: Captured payments continue at their normal rate while order creation dropped to near zero. The orders service logs a database connection error beginning at 14
  .
• Severity: critical
• Component: orders

Customers charged for nothing is the case this signal exists for, which is why the severity can be the top of the scale.

How Sazabi sets it up

The agent looks through your logs for events that belong together and decides what to count on each side. It writes and maintains the sensor, and allows for the normal lag between steps, since a payment is captured seconds before its order is written.

You do not map schemas or define joins. When you add a step to the flow or rename a message, the agent keeps the sensor current.

What you see and how you get told

You get an issue with a name, a description, a severity and the evidence from both sides, already investigated. The investigation looks at where one side stops following the other and checks nearby errors. The thread lets you ask for the affected time range or for the list of identifiers in one log but not the other, as far as the logs allow.

Issue triggered notifications reach you as configured, and delivery rules can route critical issues on a component to a shared channel. sazabi issues agent-prompt creates a prompt for a coding agent once you know what to change, and sazabi signals list --type sensor shows the signals.

What it does not cover

• It does not read databases, ledgers or provider dashboards, only what your systems log.
• It does not audit rows. Duplicate processing and writes that never reach storage are separate questions and are not covered today.
• It cannot compare a number nobody logs.
• It does not repair or replay anything.

Related

When a partner feed simply goes quiet, that is a webhook gap. A flow where output is missing without any mismatch is an empty output. Drops in volume rather than disagreement are covered under business metric drift. The manual version is the guide to reconciliation mismatches. Billing is on the pricing page.