Field Drift Alerts: Issues When Values Inside Your Events Change

Last verified on Nov 10, 2026.

What it catches

An event can keep arriving on schedule and still be wrong. The line is there, the volume is normal and nothing errors, but a field inside it has changed character. An ID is null for a slice of requests. A status field gains a value no consumer expects. A "reason" string is empty. A payload is ten times its usual size.

Field drift asks whether the values inside your events still look like they used to. It is the signal for a service that keeps running while handing bad data to everything downstream.

Concrete causes:

• A new code path writes a record without setting a required field.
• An upstream API starts returning null where it used to return a value.
• A migration adds an enum member and one consumer does not know it.
• A client sends a longer string, a larger array or an unusual encoding.
• A feature launches for one customer type and its events carry a shape nobody tested.

Example: company IDs go missing on writes

This is an example, not output from a real project. Your records-api service logs each write with the owning company:

2026-11-08T09:12:40Z INFO records-api record_written id=rec_901 company_id=c_118 source=import
2026-11-08T09:12:41Z INFO records-api record_written id=rec_902 company_id=null source=api
2026-11-08T09:12:44Z INFO records-api record_written id=rec_903 company_id=null source=api
2026-11-08T09:12:47Z INFO records-api record_written id=rec_904 company_id=c_204 source=import

The null values cluster on source=api. Sazabi opens an issue. An example of what it could say:

• Name: Writes through the API are missing company_id in records-api
• Description: A small share of record_written events now carry a null company_id. It was never null before. Every null comes from source=api.
• Severity: high

Because the nulls share one source, the agent points to the API write path as the first place to look. A volume graph would never have shown it.

How Sazabi sets it up

The Sazabi agent sets up sensors for your project and maintains them over time, and for field drift it writes them to fit your events. It reads your logs to see which fields exist and which of them matter, then writes each sensor's question. In plain words: "Tell me when the share of null company_id values on writes goes above its usual level."

The agent writes, backtests and maintains the sensors. As your services change, the agent updates the sensors, so a field you rename or add is picked up without your doing anything.

A firing records a signal and starts an investigation, which opens an issue when the drift is real and closes without one when it is harmless.

What you see and how you get told

You get an issue with the field, the events it affects and what they have in common, such as a source or route. The thread lets you ask the agent follow-ups. You can hand the fix to a coding agent with sazabi issues agent-prompt. Issue triggered notifications go to your in-app feed by default, with delivery rules for shared Slack or Microsoft Teams channels. sazabi signals list --type sensor lists the underlying firings.

What you need

Logs where fields are separate values, not buried in a sentence. Structured events give the agent the most to work with; the structured logging glossary entry explains the idea. Any supported source works, for example OpenTelemetry or AWS.

What it does not cover

• Tables and files outside your logs.
• Fields the service never logs.
• Truly new error messages, which belong to new error detection.
• Rules you write yourself. The agent decides the question and shows you the evidence.

For the vendor-neutral background on measuring this by hand, read the guide to data and schema drift. See also the data integrity category and pricing.