Detection
Detection

Saturation Alerts: An Issue When Pools, Memory or Disk Run Near Full

By Sazabi Team

Last verified on Nov 10, 2026.

What it catches

Saturation is the resource side of a slowdown. The service is healthy until some limited thing fills up, then everything queues behind it. The signal is usually visible well before the failure, because use climbs through the high eighties and nineties first. Things that fill up:

  • A database connection pool, where each new request waits for a free connection.
  • A thread or worker pool, where requests queue inside the process.
  • Memory, where garbage collection takes over and then the kernel ends the process.
  • A disk or volume, where writes start failing.
  • CPU pinned near the ceiling during peak hours.

The usual complaint after the fact is "it just got slow." Saturation is the stage before that.

Example: the pool sits at 95 percent at peak

This is an example, not output from a real project. A checkout-api service logs its database pool use every 30 seconds, and logs an error when a request gives up waiting:

2026-11-06T17:58:00Z INFO checkout-api db_pool in_use=17 size=20 waiting=0
2026-11-06T17:58:30Z INFO checkout-api db_pool in_use=19 size=20 waiting=2
2026-11-06T17:59:00Z INFO checkout-api db_pool in_use=19 size=20 waiting=4
2026-11-06T17:59:30Z INFO checkout-api db_pool in_use=20 size=20 waiting=11
2026-11-06T17:59:41Z ERROR checkout-api timed out waiting for a database connection after 5000 ms

An example issue:

  • Name: checkout-api database pool at its limit during evening peak
  • Description: In-use connections reached the pool size and requests began waiting, ending in connection timeouts. Usage has been near the pool size at peak on recent days.
  • Severity: high
  • Component: checkout-api

The analysis can show whether the pool is small or a slow query is holding connections too long, because it reads the surrounding logs.

How Sazabi sets it up

The Sazabi agent sets up sensors for your project and maintains them over time. It reads your logs to find which resources report themselves, then sets up sensors with a plain question for each, for example: "Tell me when the share of the database pool in use stays near full." A short burst does not count, and a resource that sits near full does.

You set nothing up. The agent writes, backtests and maintains the sensors, and keeps them current as your system changes, so a pool that gets resized is still judged correctly. Each service is judged on its own, so one service running full does not hide behind the others.

What you see

An issue with name, description, severity and an account of what the agent found. Unlike a graph, it says what was saturated and what was waiting on it. Ask in the thread whether the same pool saturated yesterday. Delivery rules by component let the owning team be told first.

Recurrences while the issue is open fold into it, so a daily peak does not make a pile of duplicates.

What you need

Resource usage that reaches your logs: pool stats from your code, memory and disk lines from your platform, or metrics forwarded through OpenTelemetry. Database logs from Postgres or Supabase and platform logs from AWS are common starting points.

Reading the issue

Saturation has two readings. Either demand rose past capacity, or something is holding the resource longer than it should. A pool at its limit because traffic doubled needs more capacity. A pool at its limit because one query now takes ten times as long needs that query fixed, and adding connections would make the database worse. The agent can read the slow lines that surround the saturated ones, so ask which reading the logs support before anyone resizes anything.

What it does not cover

  • Budgets that run down over time, like credits and quotas. See approaching a limit.
  • Queues that grow. See backlog growth.
  • Resources nothing reports. If memory is never logged, memory is invisible.
  • Right-sizing advice. The issue describes what filled up, not what to buy.

The golden signals entry places saturation among the basic four. For manual forecasting, see the capacity monitoring guide. 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.

  • Saturation: CPU, memory, connection pools, thread pools or disk near full. Example: Database connection pool at 95% during peaks.

Frequently Asked Questions

Which resources can it watch?

CPU, memory, connection pools, thread pools and disk, as far as your logs report them. The agent reads your logs to find the usage and size fields and builds the check around them.

Does it use one cutoff for every resource?

No. Each resource is judged as it behaves in your system. A pool that touches 95 percent in a short burst is treated differently from one that sits near full.

My database does not log pool usage. What then?

Then there is nothing to watch for that pool. Application code can usually log it, and the timeouts that follow when a pool runs out are logged lines the agent can read too.

Do I have to set it up?

No. The Sazabi agent sets up saturation sensors for your project and maintains them over time, since each system has different resources and different names for them.

Sources

  1. Issues arrive investigated with analysis and evidence, severity low to critical, ask follow-ups in the thread (accessed Nov 8, 2026)
  2. Issue triggered delivery by severity, component and owning team (accessed Nov 8, 2026)
  3. Signals feed investigations that open issues (accessed Nov 8, 2026)