How to monitor third-party provider outages with two signals

When production starts failing, one of the first questions is also one of the most expensive to answer badly:

Is our application broken, or is a provider we depend on having an incident?

If the dependency is AWS, Cloudflare, GitHub, OpenAI, Stripe, or another cloud or SaaS vendor, there are two common approaches:

1. Read the provider's official status page.
2. Probe the service yourself.

Neither is enough on its own. A useful monitoring setup treats them as separate signals.

I am Kerolos, the founder of OutageDeck. I built it to normalize official status sources across 172 providers. This post explains where that signal fits, where it does not, and how I would combine it with synthetic checks.

Signal 1: what the provider says

An official status feed tells you what the vendor has acknowledged. It can provide details a black-box probe cannot:

• the affected product or service
• the region or customer segment involved
• investigation and mitigation updates
• the incident timeline
• a recovery announcement

The problem is timing and scope. A provider may not publish an incident immediately. Its dashboard may say that the platform is operational while your account, region, route, or workload is failing.

Official status is valuable evidence, not an oracle.

Signal 2: what your users experience

A synthetic check asks a different question: can a request complete successfully from a location you care about?

Useful probes include:

• an HTTP request against a critical endpoint
• a DNS lookup through the route your users take
• a small authenticated API transaction
• a read and write against a non-production object or record
• a check from more than one region

The probe should exercise the smallest safe transaction that represents the dependency. A TCP connection to port 443 proves very little if the API is returning errors after authentication.

Synthetic monitoring also has blind spots. Your probe may fail because of your own credentials, network, DNS, deployment, or test data. It can tell you that a path is broken, but not always who owns the fault.

The useful part is the correlation

Put the two signals together and the incident becomes easier to triage:

Provider status	Synthetic probe	Working assumption
Operational	Passing	No provider incident visible
Incident	Passing	Provider issue may not affect your path
Operational	Failing	Investigate your stack, but watch for delayed provider acknowledgement
Incident	Failing	Strong evidence of an upstream dependency incident

This is a starting point, not an automatic root-cause verdict. Region, service, and account scope still matter.

A small provider-status check

OutageDeck exposes a keyless read-only API, so a quick check can be as small as:

curl -fsS https://outagedeck.com/api/v1/providers/aws \
  | jq '{
      provider: .data.name,
      status: .data.currentStatus.code,
      headline: .data.currentStatus.headline,
      checked_at: .data.source.checkedAt,
      source: .data.source.officialUrl
    }'

For a dependency stack:

providers=(aws cloudflare github openai stripe)

for provider in "${providers[@]}"; do
  curl -fsS "https://outagedeck.com/api/v1/providers/${provider}" \
    | jq -r '[
        .data.name,
        .data.currentStatus.code,
        .data.currentStatus.headline,
        .data.source.checkedAt
      ] | @tsv'
done

The source timestamp matters. A green result from stale data should not be treated as healthy.

A matching synthetic check

The independent side might start with an HTTP request:

curl --fail --silent --show-error \
  --connect-timeout 3 \
  --max-time 10 \
  -o /dev/null \
  -w 'status=%{http_code} total=%{time_total}s\n' \
  https://your-critical-endpoint.example/health

In production I would add:

• at least two probe locations
• consecutive-failure thresholds to reduce transient noise
• a dependency-specific timeout
• a safe authenticated transaction where possible
• separate alerts for probe failure and vendor acknowledgement

Do not make the provider-status lookup a hard dependency of the probe itself. If the aggregator is unreachable, the probe should still report what it observed.

A practical alert policy

I would route the combinations differently:

• Probe fails, provider reports an incident: page the on-call owner with upstream context attached.
• Probe fails, provider reports operational: page as an unclassified failure and keep polling the provider feed.
• Probe passes, provider reports an incident: send a lower-urgency warning to the service owner.
• Both pass: remain quiet.

That keeps a broad vendor incident from creating hundreds of disconnected alerts while preserving the evidence needed for triage.

What to record during the incident

For each signal, retain:

• observation time
• last successful check
• region and service
• response code or normalized state
• provider source timestamp
• incident identifier and updates

This makes the post-incident review much better. You can see whether your probes detected the problem before the provider acknowledged it, and whether your alert thresholds helped or slowed the response.

Try it without creating an account

I made a no-account dependency stack checker for the provider side of this workflow. Pick the vendors in your stack and it produces one shareable view of their official status signals. OutageDeck also exposes JSON, RSS, badges, CLI tools, and an MCP endpoint; free accounts can watch up to five providers by email.

I would like to hear how other teams correlate vendor status with their own telemetry. Which signal has been more misleading in your incidents: a provider dashboard that stayed green, or a synthetic check that blamed the wrong dependency?