Outage Clock Outage Clock
Sign up

Send vendor incidents into the tools you already run

Webhooks ship with Starter. Extra channels on Pro.

Email and Slack are fine when a person should read the message. A webhook is better when a system should act: open an incident, page an on-call rotation, or append a line to an internal log. Outage Clock can POST each vendor status change to a URL you control.

When a webhook is the right channel

  • You already run an incident tool and want vendor events next to your own alerts
  • A bot should create a ticket, not wait for someone to copy and paste
  • You want a durable record in a datastore, not a chat transcript that scrolls away
  • Different vendors should fan out to different automations

Keep Slack for people. Keep the webhook for machines.

What we send

Each POST is JSON. The body names the vendor, the component, the new status, the previous status, the vendor's latest update text, and timestamps for the change and the poll. A resolved event uses the same shape so you can close whatever you opened.

We send a shared secret header so you can reject requests that did not come from us. Rotate that secret if it leaks.

A handler that does not page you at 3am for maintenance

Filter in your code, not only in Outage Clock.

  1. Ignore maintenance unless that vendor's maintenance has burned you before.
  2. Ignore components you do not run, even if they appear in the catalog.
  3. Open an incident on major outage and partial outage. For degraded, open a ticket or post a quiet note.
  4. Close on operational using the vendor and component as the key, so two overlapping incidents do not clobber each other.

If your incident tool has a vendor or "third party" tag, set it. That keeps these pages out of the error-budget conversation for your own code.

Retries and timeouts

Your endpoint should answer in a couple of seconds with 2xx. We retry a small number of times on timeouts and 5xx. Do the slow work after you acknowledge the POST: enqueue, then return 204.

Idempotency matters. The same change can be delivered twice. Key on vendor, component and the change timestamp, and drop duplicates.

Routing ideas

  • Payments, auth and email sending: page the on-call
  • CI and the package registry: post to the engineering channel, no page
  • Chat and video: tell IT
  • Everything else: daily digest, no webhook

On Pro you can attach several destinations, so one vendor list can feed Slack and a webhook at the same time.

Questions

Can I point the webhook at Zapier or n8n?

Yes, if they give you an HTTPS URL that accepts JSON. Treat that URL like a password.

What if my handler is down?

We retry, then we stop. Watch the webhook's own health. A dead handler is worse than email, because nobody sees the miss.

Start on Starter