Cloud Provider Error Alerts: Know When AWS or GCP Starts Failing Your Calls

Last verified on Nov 10, 2026.

What it catches

Cloud APIs fail in ways your code usually survives once and does not survive a hundred times. The Sazabi agent sets up sensors for your project, and Cloud provider errors is one of the signals it writes when your logs show calls to AWS or GCP. It looks for:

• Throttling: S3 SlowDown, DynamoDB ProvisionedThroughputExceededException, a ThrottlingException from another AWS API, or RESOURCE_EXHAUSTED from a Google Cloud API.
• A burst of 5xx responses from a managed service your code writes to.
• Permission errors that start appearing on a call that worked yesterday.
• A single region or endpoint failing while the rest of your traffic is fine.

The distinction from vendor signals is the layer: this is the infrastructure your service runs on, not a third-party product it calls.

Example: uploads slow down at peak

This is an example, not output from a real project. An uploads-api service writes user files to object storage. During the evening peak the logs fill with this:

2026-11-08T19:41:12Z WARN  uploads-api put_object failed: SlowDown: Please reduce your request rate. bucket=user-uploads attempt=2
2026-11-08T19:41:13Z WARN  uploads-api put_object failed: SlowDown: Please reduce your request rate. bucket=user-uploads attempt=3
2026-11-08T19:41:15Z ERROR uploads-api upload aborted after 3 attempts user_id=20811 key=avatars/20811.png

A sensor for this could ask: "Tell me when the share of storage calls that come back throttled goes far above its usual level." Each bucket or service is judged on its own, so a hot bucket stands out instead of hiding behind the others.

The resulting issue might read:

• Name: Object storage throttling uploads-api writes to user-uploads
• Description: Throttling responses began at 19
  UTC and a growing share of uploads are being aborted after three attempts. The write rate to one key prefix is far above earlier evenings.
• Severity: medium, rising to high if aborted uploads continue

That last line is the useful part. The issue says where the throttling is concentrated, so you start with the hot prefix instead of the error count.

How Sazabi sets it up

You set nothing up. The agent reads your logs to find the cloud calls your code makes and how their failures are written, whether that is an SDK error class, an HTTP status or a provider error code. It writes, backtests and maintains the sensor. A daily peak that always brings a few throttles is normal and does not open an issue; throttling far beyond that does.

Because the agent keeps sensors current, a change in how you wrap the SDK or a new bucket does not leave the sensor watching a message that no longer exists.

What you see and how you get told

A firing starts an investigation. When the problem is real, you get an issue that arrives investigated, with the evidence from your logs attached. When it was a brief blip, the investigation closes without one. List the underlying signals with sazabi signals list --type sensor.

New issues trigger an Issue triggered notification. Delivery rules for shared Slack or Microsoft Teams channels can match on severity, component or owning team, so the team that owns the storage layer hears about it first. Ask the agent follow-up questions in the thread, for example which callers are producing most of the requests.

What you need

Your services need to log the errors they get back from cloud calls, or the provider-side logs need to reach Sazabi. Connect AWS or Google Cloud, or send logs from your own code through OpenTelemetry.

What it does not cover

• It does not read cloud provider incident feeds or status pages.
• It does not watch a quota before you hit it. Approaching a limit is a separate signal.
• It does not watch spend. Cloud spend anomalies are not covered today.
• It does not raise your quotas or change retry settings.

Related

If the failing service is a third party instead of your cloud, read vendor degradation and vendor rate limiting. The vendor-neutral view is in the guide to third-party failures. See pricing for how detected issues are billed.