Business Flow Breakage Detection: Issues When Signups, Checkouts or Orders Fall Off

Last verified on Nov 10, 2026.

When the code works and the business does not

A flow can break without a single exception. A coupon change makes every checkout total zero and the payment step never runs. A signup email stops sending, so people never finish. Engineers see healthy services, and finance sees the problem at the end of the week.

Three signals

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, and these three are about the business, not the infrastructure.

• Vanished event. Something that normally happens has stopped while traffic is normal, such as application-submitted events ceasing at 2
  pm.
• Business metric drift. Signups, applications, payments or messages are far outside their usual range, such as applications down well below usual.
• Funnel drop. Step-to-step conversion falls, for example from signup started to signup completed.

Daily and weekly rhythms, such as a quiet weekend morning, are part of the normal pattern and do not count as a drop. Other flow signals, such as an out-of-order sequence of steps, are not covered today.

Example: signups start but do not finish

This is an example, not output from a real project. Two events from the accounts-web and accounts-api services:

2026-11-08T11:20:04Z INFO accounts-web signup_started session=s_81f
2026-11-08T11:20:19Z INFO accounts-api verification_email_queued user=u_3302
2026-11-08T11:20:19Z ERROR accounts-api verification_email_failed user=u_3302 reason="sender domain rejected"

The first step still happens at a normal rate. The last step, signup_completed, has nearly stopped. A question asking whether completed signups are far below usual, or whether conversion from started to completed has fallen, is the one that matches. The issue could read:

• Name: Signups starting but not completing
• Description: Signup starts are at their usual rate, but completions have fallen sharply since 11
  UTC. Verification emails are failing with a sender-domain rejection.
• Severity: high

Notice that the cause sits in a third event, and the agent finds it by investigating around the drop.

How you hear about it

You get an issue with severity, description, analysis and evidence. A product or growth lead can be on the delivery rule by owning team, receiving only issues about the signup component, while engineers get the technical detail in the same thread. Ask the agent how many users were affected over the window, or hand the fix to a coding agent. Recurrences fold into an open issue.

Making your flow visible

A step needs to leave a trace in your project. Log an event at each important point of the flow with a stable name and the key identifiers. If the flow starts in a browser, the Sazabi browser SDK can send client events to the same project. Events from the services behind it can be sent with the integration you already use, such as an OpenTelemetry exporter.

A few habits that help

Name events after what happened in the business, such as order_paid, not after the function that logged them. Keep the name stable across releases, because a sensor asks about that name and a rename looks like the old event vanishing. Put an identifier such as an account or session on each event so the agent can follow one customer through the steps during an investigation.

Not covered today

• A step that leaves no event.
• Wrong amounts or wrong totals in a flow that completes. That is for data integrity.
• Clicks and navigation with no effect on the page.
• Revenue or cost analytics. The sensors ask about counts and rates.

Related

The browser side is on frontend breakage, and the guide to detecting new errors covers errors that do appear. A flow that stops because a service is down belongs to outages. Issues detected are metered; see pricing.