Performance Degradation Alerts: Issues for Slow Creep, Sudden Jumps and Slow Tails

Last verified on Nov 10, 2026.

Slow is a failure mode

Users notice slowness long before anything is down. A search that takes four seconds instead of one still returns results, so no error appears. Slowness also takes three different shapes, and each one needs a different question.

Six signals

The Sazabi agent sets up sensors for your project and maintains them. These feed this page:

• Latency step change. Latency jumps and stays up, usually the day a change shipped.
• Gradual latency drift. A slow climb across days or weeks that no single day makes obvious.
• Tail latency. The slowest requests get slower while the typical request stays flat.
• Boot and cold-start creep. Services take longer to become ready.
• Queue wait growth. Work waits longer before it begins.
• Web vitals regression. Page load and responsiveness get worse. The Sazabi browser SDK does not capture Core Web Vitals, so this one depends on timing data your app already sends.

A regular Monday-morning peak is part of normal behavior, so it is not a slowdown. Each route is judged on its own, so one slow endpoint fires on its own instead of vanishing inside a service-wide average.

Example: the tail moves, the middle does not

This is an example, not output from a real project. The search-api service logs one line per request:

2026-11-08T10:14:02Z INFO search-api GET /v1/search status=200 duration_ms=118 plan=free
2026-11-08T10:14:02Z INFO search-api GET /v1/search status=200 duration_ms=131 plan=pro
2026-11-08T10:14:03Z INFO search-api GET /v1/search status=200 duration_ms=4890 plan=enterprise
2026-11-08T10:14:04Z INFO search-api GET /v1/search status=200 duration_ms=5120 plan=enterprise

Most requests are fine, and every status is 200. An average hides it. A question about the slowest requests on /v1/search, by plan, does not. The issue could say:

• Name: Slowest search requests degraded for enterprise accounts
• Description: The slowest share of /v1/search requests is far above its usual level. The slow requests come from the enterprise plan, which has the largest indexes.
• Severity: medium

What you get

You get an issue with a name, description, severity, optional component and status, and the agent's analysis and evidence attached. Because the agent investigates before it opens anything, a firing that turns out to be a one-off batch job closes without an issue. A service that wobbles at the edge does not open a stream of separate issues.

Delivery rules can match severity or component. A team that owns the search service can take medium issues in Slack while everyone else sees only critical ones. You can also ask the agent in the issue thread when the slowdown began and what else changed around that time.

Keeping it useful

Three things make these sensors sharper:

• Log a duration on each request or job, in a consistent field.
• Include the dimension you suspect, such as route, plan or region, as its own field.
• Send deploy events if you can, so the agent can line up a step change with a release.

If your logs are an unstructured mix, the log parsing glossary entry explains why fields help.

What is not covered

• Services that log no timing at all and send no metrics.
• Slow database queries as their own signal. A slow query reaches Sazabi only as slowness in the service that runs it.
• Rendering problems with no timing data behind them.
• Per-user complaints. The sensors speak about groups of traffic.

Related pages

The vendor-neutral write-up, with queries and thresholds, is the performance degradation guide. For tail behavior alone, see the tail latency guide. A fully down service belongs on outages, and a resource near its limit on capacity risks. Issues detected are metered, so check pricing.