Slack Uptime Alerts with Sandglass
Keep Slack in the incident loop without promising unsupported native escalation features.
Connect Sandglass monitoring to Slack using the alert paths supported today: email, Slack webhooks, and generic webhooks for incident events.
Requirements
- A Sandglass account with at least one configured check
- A Sandglass alert policy with email, Slack webhook, or generic webhook delivery
- Slack access for the channel or workflow that should receive incident events
How to connect
Step 1: Create or choose the Sandglass checks
Use HTTP status, ping, TCP port, content, SSL certificate, or heartbeat checks depending on what should be monitored.
Step 2: Connect the supported alert channel
For Slack, paste an incoming webhook URL into the Sandglass alert policy. For other tools, use a generic webhook endpoint or route through your own automation layer.
Step 3: Send a test incident
Trigger a controlled failure or use a staging check so you can verify the event shape before relying on it for production incidents.
Step 4: Tune routing after the first week
Review noise, retry windows, and ownership. Keep production and non-production alerts separate.
What you can do
- Incident open and recovery events: Sandglass can send notifications when checks fail and when they recover through configured email, Slack webhook, or generic webhook destinations.
- Works across monitor types: The same alert policy can cover uptime checks, ping checks, TCP checks, content checks, SSL certificate checks, and heartbeat checks.
- No unsupported native connector required: This page stays within the current product surface and does not claim native escalation connectors that are not implemented.