Capacity Risk Alerts: Issues When a Pool, Queue or Quota Heads for Its Limit

Last verified on Nov 10, 2026.

Trouble that is visible before it hurts

A capacity risk is a resource heading toward a limit while everything still works: a connection pool, a thread pool, a disk, a queue, an API quota. The limit is hit later, usually at peak traffic, and then looks like an outage. The warning is in the logs hours or weeks ahead.

Seven signals, all written for your system

These limits belong to your stack, so the Sazabi agent sets up sensors for the resources it finds in your logs. It writes, backtests and maintains them, and keeps them current as your system changes. You set nothing up.

• Saturation. CPU, memory, connection pools, thread pools or disk near full.
• Approaching a limit. Cloud quotas, burst credits, API rate limits, file handles or plan limits running low.
• Backlog growth. A queue that grows faster than it drains.
• Crash loops. Restarts, out-of-memory kills and failing health checks, often what memory pressure becomes.
• Boot and cold-start creep. Services taking longer to start, which can follow a drained resource.
• Vendor rate limiting. A provider throttling your requests, such as 429s from an LLM API at peak.
• Cardinality jump. A field suddenly carrying far more distinct values, such as thousands of new cache keys a minute.

Some signals in this category are not covered today, including a warning about an expiring certificate.

Example: a pool that peaks near full

This is an example, not output from a real project. The orders-api service logs its database pool at regular intervals:

2026-11-08T12:00:00Z INFO orders-api db_pool in_use=22 max=50 waiting=0
2026-11-08T12:30:00Z INFO orders-api db_pool in_use=41 max=50 waiting=0
2026-11-08T13:00:00Z INFO orders-api db_pool in_use=48 max=50 waiting=6

No error appears at 13

An example issue:

• Name: orders-api database pool close to its limit at peak
• Description: In-use connections reached 48 of 50 and requests began waiting. The peak is higher each day this week, tracking order volume.
• Severity: medium

What the issue gives you

The agent investigates before it opens the issue, so the analysis can show how the reading has moved, not just its latest value. From the issue you can ask it follow-up questions, such as which endpoint holds connections longest, then hand a fix to a coding agent. Severity decides routing: a pool at its maximum during a sale may be high, while slow drift in a disk reading is usually low.

Capacity warnings are easy to defer, so delivery rules help. Send low and medium issues for the platform component to a weekly-reviewed channel, and send high ones to whoever is on call.

Getting the readings in

Capacity sensors need the number. Two routes work:

• Write the reading into a log line, as above.
• Send OpenTelemetry metrics to the same project through the OpenTelemetry integration. Metric data points arrive through the same intake as logs.

Cloud-side limits, such as burst credits, show up if you forward platform logs, for example through the AWS integration.

What it does not do

• It does not read a resource that is never logged or sent as a metric.
• It does not plan purchases or size clusters.
• It does not forecast an exact time of failure.
• Generic changes in the log stream, such as a jump in log volume, are on the log volume spikes page.

Related

The query-level view is in the capacity risks guide, and the cardinality jumps guide covers one signal in depth. When a limit is actually hit, you will be on the outages or performance degradation page. Issues detected are metered; see pricing.