Latency Drift Alerts: An Issue When Responses Get Slower Week by Week

Last verified on Nov 10, 2026.

What it catches

Gradual latency drift is the slowdown nobody gets paged for. A route is a little slower each week, so no single day looks wrong, and a year later it is twice as slow. Common causes:

• A table grows until an index stops helping the query.
• A cache hit rate decays as the key space widens.
• Each release adds one more downstream call to a hot path.
• A list endpoint returns more rows per customer every month.

The Sazabi agent sets up sensors for your project, and a latency-drift sensor is one of them. Sensors are standing questions about your logs, and this one asks: "Is any route's latency steadily climbing past its usual level?" You set nothing up, and you do not pick a route, a percentile or a threshold.

Example: search gets slower every Monday

This is an example, not output from a real project. Your search-api service logs one line per request. These four lines are from the 09

2026-10-13T09:14:02Z INFO search-api GET /v1/search status=200 duration_ms=388 results=24
2026-10-20T09:14:11Z INFO search-api GET /v1/search status=200 duration_ms=431 results=24
2026-10-27T09:14:07Z INFO search-api GET /v1/search status=200 duration_ms=467 results=24
2026-11-03T09:14:09Z INFO search-api GET /v1/search status=200 duration_ms=509 results=24

Same route, same result count, no errors. Every week is slower by a similar step. No deploy lines up with the change, which is why a person tends to miss it.

An issue could read:

• Name: Search latency rising steadily on GET /v1/search
• Description: Responses for the route have slowed a little more each week for the past month, with no matching error increase.
• Severity: medium
• Component: search-api

The analysis would then lay out the evidence it found: the week-by-week change, and which slice of requests moved.

How Sazabi sets it up

You set nothing up. The Sazabi agent sets up sensors for your project and maintains them over time. In plain words, the question is: "Tell me when a route's latency keeps climbing past its usual level." You do not write it, and renaming a route does not break it, because it asks about the logs it sees.

What that means in practice:

• Regular daily and weekly rhythms, such as a Monday morning rush, do not count as drift.
• Each route is judged on its own, so one slow route does not hide behind healthy totals, and the issue names the route.
• The climb has to be steady. A single slow day is not drift.

What you see and who hears about it

When the answer is "yes," Sazabi records a signal and starts an investigation. If the drift is real, you get an issue that arrives with its analysis already attached. If the investigation finds it harmless, it closes without one. sazabi signals list --type sensor shows the signals either way.

Because drift is rarely urgent, many teams will want it routed to an owning team rather than to whoever is on call. A delivery rule on severity, component or owning team does that. See Slack for a shared channel.

What you need

Request durations in your logs. Access logs from a load balancer or CDN work, as do application logs with a duration field and OpenTelemetry data. See integrations for sources. For Cloudflare or AWS traffic, point the log source at the edge or the load balancer.

If durations are not logged anywhere, there is nothing to compare. Check the Intake page to confirm the data arrives.

What it does not cover

• A slowdown that arrives in one deploy. That is a step change, and it is a separate detection.
• Latency that is slow from day one. Drift is a climb, so the route has to start faster.
• Services that do not log how long a request took.
• Browser-side slowness. Sazabi does not capture Core Web Vitals.

For the vendor-neutral method of finding drift by hand, read the latency monitoring guide. For percentile vocabulary, see latency percentiles. Issues Sazabi detects are metered, so check pricing.