Dependency Failure Alerts: Issues When a Vendor, Cloud API or Webhook Feed Fails

Last verified on Nov 10, 2026.

The failure is somebody else's, the outage is yours

Your code calls a payment API, a cloud storage service, a language model, an email provider. When one of them degrades, your service degrades with it, and the first evidence is in your own logs: more timeouts, 429s, a field that comes back empty, a webhook that never arrives.

Who sets this up

The vendors in your stack are specific to you, so the Sazabi agent reads your logs to find the third parties your code calls and sets up sensors for each. The agent keeps all of them current as vendors come and go. You set nothing up. Five signals are live here:

• Webhook gap. Inbound webhooks you expect have stopped arriving.
• Vendor degradation. Errors or latency from a provider you depend on.
• Vendor rate limiting. The provider is throttling your requests.
• Cloud provider errors. Throttling or errors from AWS or GCP APIs.
• Contract change. A vendor's response shape changed, such as a field your code relies on arriving empty.
• LLM behavior drift. Model output changed in length, refusals, malformed JSON or token use.

Each vendor is judged on its own, so a sluggish email provider stands out without muddying a healthy payment API.

Example: a vendor starts throttling

This is an example, not output from a real project. The notify-service sends mail through a provider and logs each call:

2026-11-08T16:02:11Z INFO  notify-service provider=mail-api status=202 duration_ms=240
2026-11-08T16:41:30Z WARN  notify-service provider=mail-api status=429 retry_after_s=30
2026-11-08T16:41:31Z WARN  notify-service provider=mail-api status=429 retry_after_s=30
2026-11-08T16:41:33Z ERROR notify-service provider=mail-api gave up after 3 attempts

One 429 is routine. A rising share of them on one provider is a dependency problem, and it shows up several minutes before users report missing emails. An example of the issue:

• Name: mail-api rate limiting notify-service
• Description: The share of 429 responses from mail-api has risen well above its usual level, and some sends are being dropped after retries.
• Severity: high

The agent compares the provider's other calls and your recent deploys, then says whether the cause looks like your volume or their side.

What lands in your inbox

An issue, stable-named, with severity, the agent's explanation and the evidence. Recurrences while it is open or ignored fold in. If you have a Slack or Microsoft Teams channel for the owning team, a delivery rule can send Issue triggered there for that component only.

You can ask the agent in the thread whether other vendors are affected, then forward the analysis to the vendor with the evidence attached.

Getting the calls into your logs

Log each outbound call with a vendor name, status and duration, and each retry as its own line. If you run OpenTelemetry client instrumentation, those spans arrive too. Cloud API errors come through forwarded platform logs, such as with the AWS integration. Webhook endpoints should log each delivery they receive.

Questions to ask in the thread

The issue keeps the log lines it relied on, so you can paste them into a support ticket with the vendor. A useful first question for the agent is whether your own request volume changed or only this provider's error share did. A rate-limit issue that follows a traffic spike points at your usage, and errors from one provider while your volume is flat point at theirs. You can also ask which other calls to the same vendor were affected, and whether a recent deploy touched the client code.

Not covered today

• A dependency that you call without logging anything.
• A slow database or cache as its own signal.
• A new vendor incident matched against a public status feed.
• A change in which dependencies your code uses.

Related

For the same topic without Sazabi, read the third-party failures guide, the vendor degradation guide and the webhook gaps guide. Related pages are outages and data integrity. Issues detected are metered; see pricing.