Approaching Limit Alerts: An Issue Before a Quota, Credit or Limit Runs Out

Last verified on Nov 10, 2026.

What it catches

Some failures are scheduled. A budget is draining, and on a known day or hour it reaches zero. This page covers the budgets that run down: they are checked too late, usually by the failure they cause. Examples:

• A file system's burst credits run down overnight and the next morning every boot is slow.
• An API key's daily quota is spent by noon.
• The open file handle count creeps toward the process limit.
• A usage-based plan cap sits a few days away at the current rate.
• A vendor reports the remaining requests in each response, and the number keeps dropping.

The catch is the ratio of time left to time to react. An alert at zero is an outage notice.

Example: a rate limit budget drains

This is an example, not output from a real project. A sync-worker service calls a partner API and logs the headroom the partner reports in each response:

2026-11-07T08:00:12Z INFO sync-worker partner=orders-api status=200 ratelimit_remaining=4120 ratelimit_limit=5000
2026-11-07T09:00:09Z INFO sync-worker partner=orders-api status=200 ratelimit_remaining=2975 ratelimit_limit=5000
2026-11-07T10:00:14Z INFO sync-worker partner=orders-api status=200 ratelimit_remaining=1810 ratelimit_limit=5000
2026-11-07T11:00:11Z INFO sync-worker partner=orders-api status=200 ratelimit_remaining=640 ratelimit_limit=5000

Every call succeeded. At this pace the budget is gone before noon. An example issue:

• Name: orders-api rate limit budget nearly spent
• Description: The remaining request budget for partner orders-api has fallen every hour today and will run out well before the window resets.
• Severity: high
• Component: sync-worker

The analysis can say which job is burning the budget, using the other fields on the same lines.

How Sazabi sets it up

The agent writes this one. Limits differ for every system, so the Sazabi agent reads your logs for the fields that carry them and sets up sensors around what it finds. The sensors docs say the agent covers what only your system knows: the events, fields, jobs and vendors your code calls.

The agent writes the question in plain terms, something like: "Tell me when the remaining request budget for a partner falls below what a normal day leaves." You set no thresholds, and the agent maintains the sensor as your limits change.

A limit it can watch is one your logs show.

What you see

A firing records a signal, and an investigation decides if the trend is real. Real ones arrive as an issue with severity, a description and the evidence behind it. Ask in the thread which job is the heavy consumer. A high severity here is a prompt to act today, not a postmortem.

For something this time-sensitive, send Issue triggered to a shared channel with a delivery rule on severity. Reading the signal list is also possible from the CLI.

What you need

Headroom written somewhere you already forward. Logs from AWS services, or your own code that logs the vendor's rate limit headers, both work. See integrations and the OpenTelemetry source for metrics.

Reading the issue

Time to zero is the number that matters, so look at the rate of decline and not the current level. A budget at 60 percent that is falling fast is more urgent than one at 20 percent that is flat. Then find the consumer. Logs that carry a job name, a tenant or an endpoint next to the headroom let the agent say what is spending it. Decide whether to slow the consumer down, raise the limit with your provider or both, before the budget reaches zero.

What it does not cover

• Resources that are full right now. See saturation.
• Limits no log or metric exposes.
• A vendor-side outage unrelated to your quota.
• Raising a quota. You still ask your provider.

Issues Sazabi detects are metered, so check pricing. For the by-hand version of this idea, the capacity monitoring guide covers forecasting.