Detection
Detection

Latency Step Change Alerts: An Issue When Response Time Jumps and Stays Up

By Sazabi Team

Last verified on Nov 10, 2026.

What it catches

A step change is a jump from one latency level to another that then stays there. The curve looks like a staircase, not a slope. The usual causes are a change you made:

  • A release adds a synchronous call to a hot path.
  • A config change shrinks a connection pool or turns off a cache.
  • A migration drops an index the main query used.
  • A dependency upgrade quietly changes a timeout or a retry policy.

Sometimes the cause is outside your code, such as a database failover or a noisy neighbor. The detection does not need to know which. It sees that the level moved.

The Sazabi agent sets up sensors for your project and maintains them, and latency step change is one of them. Nobody has to choose a number of milliseconds.

Example: checkout slows down after the 16
release

This is an example, not output from a real project. The checkout-api service logs request durations, and the pipeline logs a deploy line at 16

UTC.

2026-11-06T16:11:48Z INFO checkout-api POST /v1/checkout status=200 duration_ms=312 cart_items=3
2026-11-06T16:19:30Z INFO checkout-api POST /v1/checkout status=200 duration_ms=298 cart_items=2
2026-11-06T16:20:05Z INFO deploy-hook service=checkout-api version=2026.11.06-3 status=rolled_out
2026-11-06T16:24:12Z INFO checkout-api POST /v1/checkout status=200 duration_ms=1187 cart_items=3
2026-11-06T16:24:51Z INFO checkout-api POST /v1/checkout status=200 duration_ms=1204 cart_items=2

Nothing errors. Every request still succeeds, so an error-based alert stays silent. An example issue:

  • Name: Checkout latency jumped to a new level after release 2026.11.06-3
  • Description: Typical POST /v1/checkout latency moved from about 300 ms to about 1.2 s at 16
    UTC and has held there.
  • Severity: high
  • Component: checkout-api

The issue arrives with the agent's reading of the evidence: when the level moved, that it lines up with the rollout, and that all cart sizes were affected.

How Sazabi sets it up

You set nothing up. The plain-language question is: "Tell me when response time for a route goes far above its usual level and stays there." A busy Friday evening is part of a route's usual pattern, so only a jump far outside it counts, and a brief wobble does not.

What happens next

The firing records a signal and starts an investigation. When the jump is real you get an issue. When it is harmless the investigation closes without one.

Inside the issue thread you can ask things like "which deploy was this?" with the issue context loaded. If a release is the culprit, sazabi issues agent-prompt produces the prompt to hand to a coding agent. Rolling back is still your call.

A deploy line in the same logs helps the thread, because the agent can read it beside the slow requests. If your pipeline can write one, let it.

What you need

Durations in your logs, from an access log, an application log or OpenTelemetry data. A load balancer log from AWS is enough to start. Sources are listed under integrations.

Reading the issue

Start with the time the level moved, because it is the one fact that narrows the cause. If it matches a release, look at what changed in that release's hot path. If it matches nothing you shipped, look underneath: a database failover, a changed dependency timeout or a cache that was flushed. Then check whether every route moved or only one. A single route points at code. Every route at once points at shared infrastructure. The issue thread is the place to ask each of those questions with the evidence already loaded.

What it does not cover

  • A slow creep that never jumps. That is latency drift.
  • Errors that arrive without any latency change. A new kind of error is covered by new error detection.
  • Slowness in code paths that log no durations.
  • Rolling back, or blocking a release before it ships.

For the by-hand version with release slices, read the latency spikes guide. To think about how much slowdown a canary should tolerate, see canary deployment. Issues Sazabi detects are metered, so check pricing.

What Sazabi detects today

There are no monitors or alert rules to write: the Sazabi agent automatically sets up sensors for your project and maintains them over time. Sazabi opens an issue when one fires.

  • Latency step change: A sudden jump in latency. Example: Page load goes from 300ms to 1.2s after a deploy.

Frequently Asked Questions

Does a one-minute blip open an issue?

No. A firing starts an investigation, and the investigation decides whether the problem is real. A short blip that passes on its own closes without an issue.

Do I have to send deploy events?

No. The detection works from the latency in your logs. If your pipeline already writes a deploy line to your logs, the agent can read it during the investigation and say whether the jump lines up with a release.

Will it fire again while the service is still slow?

While an open or ignored issue exists for the problem, a recurrence folds into it instead of opening a duplicate. After you resolve the issue, a new jump opens a new one.

What about slow requests that only affect a few users?

That is the tail latency detection, which looks at the slowest requests rather than the typical one.

Sources

  1. Issue contents, severity, thread questions, agent prompt for a coding agent, resolve, ignore and mute (accessed Nov 8, 2026)
  2. sazabi signals list with the sensor type filter (accessed Nov 8, 2026)
  3. Signals as events Sazabi detects, investigation that opens issues that arrive investigated (accessed Nov 8, 2026)
Catch the next slow deploy with Sazabi