Correctness Issues: When the System Runs but the Result Is Wrong

Last verified on Nov 10, 2026.

What the group covers

Nothing crashed, and the dashboard is green. A week later someone notices that welcome emails stopped going out, that half the new accounts have an empty company, or that the billing system and the order system disagree about last Thursday. These are correctness problems. The system ran, and the result was wrong.

Sazabi groups these under one issue group so they open as their own kind of issue, separate from the visible failures on the reliability issues page. The group has three categories: data integrity, business flow breakage and configuration drift.

Signals that feed it

The Sazabi agent sets up sensors for your project and maintains them over time. Seven live signals open correctness issues.

Business flow breakage

• Vanished event: something that normally happens stops while traffic stays normal.
• Business metric drift: signups, applications, payments or messages are far outside their usual range.
• Funnel drop: conversion from one step to the next falls.

Data integrity

• Stale data: caches and sync jobs stop refreshing.
• Field drift: values inside events shift, such as new categories, nulls or empty strings.
• Contract change: a vendor's response changes shape.
• Reconciliation mismatch: counts disagree between systems.

Example: signups succeed, welcome emails stop

This is an example, not output from a real project. A deploy changes how the accounts service hands work to the mailer. Signups still complete, so no error appears anywhere:

2026-11-08T14:02:11Z INFO  accounts-api signup completed account=a_8841 plan=team
2026-11-08T14:02:11Z INFO  accounts-api queued welcome_email account=a_8841
2026-11-08T14:02:14Z INFO  accounts-api signup completed account=a_8842 plan=free
2026-11-08T14:02:14Z INFO  accounts-api queued welcome_email account=a_8842

The mailer log used to show a welcome_email delivered line a few seconds after each of these. It no longer does. A vanished-event sensor asks, in effect, whether the event that follows signups is still showing up at its usual rate. Sazabi investigates and opens something like this:

Welcome emails stopped after the 14

deploy (high, component: accounts). Signups continue at a normal rate, but welcome_email delivered has not been logged since 13

. The queue call still succeeds. Evidence: the last delivered line, the deploy that came right after it, and the unchanged signup rate.

You get the finding and the evidence together, so the first question is "should we roll back?" rather than "what is going on?".

How the detections are set up

You set nothing up. The Sazabi agent sets up sensors for your project and maintains them over time. Sensors are standing questions about your logs. For business flow and stale data, the questions are: did an event vanish, is a business count far outside its usual range, has something stopped refreshing.

The other four depend on names only your system knows: which field matters, which two counts should agree, which vendor response your code relies on, which steps make up a funnel. The agent reads your logs to find them, writes the sensors and maintains them as your system changes.

Regular rhythms are part of normal, so a quiet Sunday does not look like a failure.

What you see and how you are told

A detection records a signal and starts an investigation. If the problem is real, an issue opens with a name, description, severity, optional component, the agent's analysis and the evidence. If the cause is harmless, the investigation closes without one. Recurrences of an open issue fold into it, while a recurrence of a resolved issue opens a new one.

The Issue triggered notification reaches you in the app, by email, Slack DM or SMS, and shared Slack or Microsoft Teams channels follow delivery rules by severity, component or owning team. You can ask the agent follow-up questions in the issue thread, and sazabi issues agent-prompt hands the fix to a coding agent. List the signals behind your issues with sazabi signals list --type sensor.

What it does not cover

• Configuration drift has no live detection today, so a flag or setting that differs between environments will not open an issue.
• Writes that are acknowledged but never stored, and work that is processed twice, are not covered today.
• A sensor reads your logs. If the wrong result never shows up in anything you log, there is nothing to compare.

For vendor-neutral background, see the data drift guide and the reconciliation guide. Issues detected are a metered dimension, so check pricing. Logs reach Sazabi through OpenTelemetry and other routes listed under integrations.