Webhook Alerts: Pipe Sandglass Incidents Anywhere

Q: What is the payload schema?

The payload includes incident and monitor context plus the event detail. Inspect it with a temporary receiver before building production automation around it.

Q: How do I verify the webhook actually came from Sandglass?

Use an unguessable endpoint URL or a token that your receiver validates before processing the notification.

Q: How does Sandglass handle webhook failures?

Treat webhook delivery as best-effort and keep email or Slack webhook delivery configured for critical production checks until you have verified your receiver under real incident conditions.

Q: Can I filter which events the webhook receives?

Today every webhook receives every event for its group. Per-event filtering is on the roadmap. Most teams handle filtering on the receiver side with a small if-statement on `event_type`.

Q: Is the webhook payload size bounded?

Yes — payloads are bounded to a few KB. We never include full HTTP response bodies in the payload, only error summaries. If you need the full response body for an incident, follow the link back to the Sandglass incident page in the payload.

The escape hatch for tools we have not built a native integration for yet.

Sandglass POSTs incident notifications to any URL you configure. Use generic webhooks for in-house tools, custom dashboards, or automation workflows that can receive HTTP requests.

Requirements

A reachable HTTPS endpoint that accepts POST requests
A Sandglass group with at least one check
Comfort with receiving HTTP POST requests

How to connect

Step 1: Build or pick the receiving endpoint

The endpoint needs to accept HTTPS POST requests and respond with 2xx. You can write a small Lambda, a serverless function on Vercel/Cloudflare, an automation workflow, or a custom internal service.

Tip

For quick experimentation, https://webhook.site gives you a disposable URL that displays incoming payloads — useful for inspecting the Sandglass body before you write any handler code.

Step 2: Add the webhook to your Sandglass group

In Notifications, add a new Webhook channel and paste the URL. Optionally configure an Authorization header value (used as a static bearer token by Sandglass on every request).

Step 3: Send a test event and inspect the payload

Use a staging check or a temporary endpoint to inspect the notification body. Verify your handler parses it correctly before routing production incidents through the endpoint.

Step 4: Implement idempotency on your side

Your receiver should be safe to call more than once. Store the monitor and incident identifiers you receive so your downstream system does not double-process the same incident.

What you can do

Integrate with anything: A webhook is the universal integration: anything with an HTTP endpoint can receive Sandglass incident notifications. Use it to push incidents into a custom workflow, your internal incident database, or another system you control.
Structured payload with event types: The notification body includes incident context, monitor metadata, and the failure detail your receiver needs for routing.
Auth header support: Use a private receiving URL or a static token checked by your receiver to prevent unauthenticated POSTs from spoofing incidents.
Multiple webhooks per group: You can register more than one webhook URL per group. Useful for forwarding to multiple downstream systems at once.

Frequently Asked Questions

What is the payload schema?

How do I verify the webhook actually came from Sandglass?

How does Sandglass handle webhook failures?

Can I filter which events the webhook receives?

Is the webhook payload size bounded?

Pipe Sandglass into your stack with a single POST

Start free

Free plan, no credit card required.