Status

Component health and the last 90 days at a glance. This page is static HTML, updated by hand after incidents — for machine-readable checks, poll GET https://api.third-party-api.com/v2/health (no key needed, doesn't count against your quota).

Components

API api.third-party-api.com

Operational99.96% over 90 days
normal degraded outage each cell = 1 day, oldest on the left · blank cells at the right edge are today, in progress

Dashboard app.third-party-api.com

Operational99.99% over 90 days

Webhooks hooks.third-party-api.com

Operational99.92% over 90 days

Incident history

14 January 2026, 07:41–09:58 GMT · API

Elevated error rates on /verify/emailResolved

Roughly 8% of mailbox-probe requests returned 503 upstream_timeout for two hours and change. Verification without probing, geolocation and enrichment were unaffected, so plenty of customers didn't notice — the ones who did noticed hard, because their bulk jobs raced through retries and burned quota.

What happened

One of our upstream SMTP-probe providers silently changed its connection behavior after a maintenance window and started holding connections open until our timeout fired. Our circuit breaker was configured per region, and the bad provider's traffic happened to be pinned to the region carrying most European batch traffic, so the breaker in the other region never tripped and kept routing into the sludge.

What we did

What we're doing about it

8 December 2025, 22:03 (GMT) – 9 December 2025, 00:47 GMT · Webhooks

Webhook delivery backlog and duplicate deliveriesResolved

Batch-completion webhooks queued up behind a stuck consumer and then, once unblocked, delivered both the original and the retry for about a third of events. Nothing was lost — but if your handler isn't idempotent, you may have processed some batches twice.

What happened

A deploy at 21:50 changed the consumer's deserialization of a field that had, in rare cases, a string where a number was expected. The consumer crashed on those events, the queue drained into a dead-letter path nobody was paging on, and the alert we did have only watched queue depth on a 15-minute average — which the backlog crossed slowly enough to stay under threshold. We only found it because a customer emailed us. That's the embarrassing part.

What we did

What we're doing about it

Scheduled maintenance is announced at least 72 hours ahead on this page and the forum. Release notes live in the changelog.