Business Metric Drift Alerts: An Issue When Signups or Payments Fall Out of Range

Last verified on Nov 10, 2026.

What it catches

A broken checkout does not need to throw an error to cost you money. A button stops submitting, a script is blocked, an upstream step times out and users leave. The Sazabi agent sets up sensors for your project and maintains them, and Business metric drift is one of them. It watches the volume of the events a business lives on, such as:

• Signups completed.
• Applications or orders submitted.
• Payments that succeed.
• Messages sent or delivered.

It fires when one of these moves far outside its usual pattern. The question is not "is it low" but "is it unusually low right now".

Example: applications drop after a release

This is an example, not output from a real project. Your applications service logs one line each time a candidate completes an application. Normally there are dozens an hour.

2026-11-08T15:12:19Z INFO  applications submitted application_id=a_1031 source=web
2026-11-08T15:12:44Z INFO  applications submitted application_id=a_1032 source=web
2026-11-08T15:48:03Z INFO  applications submitted application_id=a_1033 source=web
(three lines in the last hour, where dozens are normal)

The sensor's question comes down to: "Tell me when the number of applications submitted in an hour is far from its usual pattern." Everything in your logs can be quiet: no errors, no alerts, no pages. The only thing missing is the people.

An example issue:

• Name: Applications down sharply from their usual pattern
• Description: Submitted applications fell from about 15
  UTC while page views to the form continue. Client errors from the form page began at the same time, after the 14
  release.
• Severity: high
• Component: applications

The link to client errors in that description is the useful part. A low count alone is a symptom, and the issue ties it to a cause.

How Sazabi sets it up

You set nothing up. The Sazabi agent sets up sensors for your project and maintains them over time, with no list of metrics for you to keep. A normal overnight trough or weekend dip is part of the usual pattern and does not count as drift.

When it fires, an investigation looks at the rest of the logs for a reason. Many drops have a cause visible elsewhere: a deploy, an upstream failure or a spike of errors on one page. If the drop is a holiday, a campaign ending or a quiet day, the investigation closes with no issue.

What you see and how you get told

You get an issue with severity and evidence, and an Issue triggered notification through your usual channels. Delivery rules can send a high issue for a component to the team that owns it. Later firings on the same problem fold into an open issue. In the thread you can ask what changed at the minute the curve bent, or which customer segment is missing. sazabi signals list --type sensor lists the underlying signals.

What it does not cover

• It only counts events your application logs. Business numbers that never reach a log are out of view.
• It does not forecast revenue or judge targets. It only notices volume far outside its usual pattern.
• It does not look into your analytics tools or your payment provider's dashboard.
• It cannot tell a marketing campaign from an outage without the evidence in your logs.

Related

For two systems that disagree rather than one that is low, use reconciliation mismatches. If the cause is on the browser side, see client errors and frontend breakage. An inbound feed going quiet is a webhook gap. Read about alert fatigue for why the investigation step exists, and see pricing.