Vendor Rate Limit Alerts: An Issue When a Provider Starts Throttling You

Last verified on Nov 10, 2026.

What it catches

A vendor limit is a quiet kind of outage. Requests still go out, some come back refused, and your retries hide the damage until the queue grows or users notice. The Sazabi agent sets up sensors for your project, and Vendor rate limiting is one of the signals it writes for the providers your code calls. It looks for:

• A rising share of HTTP 429 responses from a provider.
• Vendor-specific wording such as "rate limit exceeded", "too many requests" or "quota exceeded" in your error logs.
• A retry-after hint showing up on calls that never needed one.
• Throttling that hits one customer, one API key or one endpoint while the rest are fine.

Example: an LLM provider throttles at peak

This is an example, not output from a real project. A summarize-worker calls an LLM provider and logs each failure with the retry hint it received.

2026-11-08T15:03:11Z WARN  summarize-worker llm call throttled provider=llm-provider status=429 retry_after_s=8 model=large-1
2026-11-08T15:03:19Z WARN  summarize-worker llm call throttled provider=llm-provider status=429 retry_after_s=8 model=large-1
2026-11-08T15:03:27Z ERROR summarize-worker giving up after 5 attempts job_id=j_9031 provider=llm-provider

A sensor for this might ask: "Tell me when the share of LLM calls that come back throttled goes far above its usual level." It can be split by provider and by model, which matters here because one model tier may be limited while another is not.

An example issue:

• Name: LLM provider throttling summarize-worker calls on large-1
• Description: Throttled responses began at 15
  UTC and some jobs now fail after five attempts. Calls to the smaller model are unaffected. Job volume is well above its usual level.
• Severity: high

The point of the last sentence is the cause. The analysis weighs whether the vendor tightened a limit or your own traffic grew past it, using what is in your logs.

How Sazabi sets it up

The agent finds the vendor calls by reading your logs, learns how each vendor writes a refusal and writes the sensor. You set nothing up. Normal retries that your code absorbs do not count as an incident. The agent keeps the sensor current when you add a vendor, change an SDK or move to a new model.

You do not enter vendor names, limits or tokens-per-minute figures. If you know of a limit worth tracking that the agent has not picked up, you can ask support for a specific sensor in plain words.

What you see and how you get told

You get an issue that arrives investigated, with severity, evidence and a description of what is throttled. Further firings fold into the issue while it is open or ignored. In the thread, ask for the ten busiest callers or whether the throttling started before or after a deploy. Delivery rules can send it to the owning team's channel by component or severity. When you decide to add backoff, a queue or a second key, sazabi issues agent-prompt produces a prompt for a coding agent.

Signals underneath the issue are listed with sazabi signals list --type sensor.

What it does not cover

• It only reacts to refusals your code logs. A vendor that silently drops work is not a rate limit as far as logs go.
• It does not read the vendor's dashboard, headers you do not log or billing tier.
• It does not raise limits. That is a request to the vendor.
• Throttling by your own API gateway is not a vendor signal.

Related

The failure often travels with others. A provider that responds slowly is vendor degradation, and throttling from AWS or GCP is covered under cloud provider errors. If your LLM calls get refused and then the output changes, see LLM behavior drift. The integrations list shows what you can connect, and pricing explains metered issues.