Vendor Degradation Alerts: Catch a Slow or Failing Provider From Your Own Logs

Last verified on Nov 10, 2026.

What it catches

Most vendor trouble shows up in your logs well before anyone writes a status post. The Sazabi agent sets up sensors for your project, and Vendor degradation is one of the signals it writes for the providers your code calls. The failure modes it looks for:

• Response times from one provider climbing while your own code is unchanged.
• A higher share of 5xx responses or timeouts on one endpoint.
• A provider that answers, but with errors only for one region, plan or customer group.
• A call that used to complete in one attempt now needing several.

This page is about quality of service. A vendor that tells you "slow down" is vendor rate limiting. A response that changes shape is an API contract change.

Example: a payment API slows down

This is an example, not output from a real project. Your checkout service calls a card processor on every purchase and logs each call with its duration.

2026-11-08T13:20:04Z INFO  checkout charge ok vendor=card-processor endpoint=/v1/charges duration_ms=412
2026-11-08T13:41:50Z INFO  checkout charge ok vendor=card-processor endpoint=/v1/charges duration_ms=1630
2026-11-08T13:42:11Z WARN  checkout charge timeout vendor=card-processor endpoint=/v1/charges after_ms=5000
2026-11-08T13:42:31Z ERROR checkout charge failed vendor=card-processor status=503 attempt=2

The sensor asks something like: "Tell me when the slowest charge requests to the card processor take far longer than usual." It watches each vendor and endpoint separately, so a slow /v1/charges fires on its own while /v1/customers stays quiet.

An example issue:

• Name: card-processor charge calls slow and timing out from checkout
• Description: Since 13
  UTC charge calls take several times longer than usual and some time out after five seconds. Refund and lookup calls to the same vendor look normal.
• Severity: high
• Component: checkout

The agent's analysis separates this from a problem in your own code by showing that the slowdown sits on one outbound call.

How Sazabi sets it up

You do not register vendors. The agent reads your logs to find the outbound calls, how each one records its result and duration, and which ones matter to the business. It writes the sensors for the ones that matter. A vendor that is always slow at the same regular time is part of its usual pattern, so only a slowdown far outside it counts. The agent keeps its sensors current as you add or swap vendors.

What you see and how you get told

Each firing is a signal that starts an investigation, and a real problem becomes an issue with the evidence attached. While the issue is open or ignored, further firings on the same problem fold into it. A provider that recovers and wobbles again stays one issue instead of many.

sazabi signals list --type sensor lists the signals. Issue triggered notifications go to the people you pick, and delivery rules for a shared Slack or Teams channel can match on severity, component or owning team. In the thread you can ask the agent whether the slowdown hit every customer or only some.

What it does not cover

• It only sees calls your code logs. A vendor failure that leaves no log line on your side goes unseen.
• It does not probe vendors on a schedule or check their status pages, and it does not match your logs to published vendor incidents.
• It cannot fix anything on the vendor side. A fallback, a queue or a retry stays in your code. Hand that change to a coding agent with sazabi issues agent-prompt.

Related

Read the vendor-neutral guide to monitoring third-party dependencies for how to do this by hand. If your own cloud is the failing layer, see cloud provider errors. Webhooks that stop arriving have their own page on webhook gaps. Detected issues are billed per pricing.