Connect a Slack webhook

Before you connect Slack

Slack delivery should be part of an alert policy, not merely another destination. Decide which channel owns the response, which incident events belong there, and who is expected to act.

Use a dedicated operational channel for confirmed incidents rather than a high-volume general channel. A destination name such as Platform incidents or Customer API operations remains understandable when several integrations are configured.

The current customer-facing catalog supports Slack incoming webhooks. Broader integration types can share the same catalog and delivery architecture later, but do not assume an unlisted provider is available today.

Create an incoming webhook in Slack

In Slack, create or choose an app with Incoming Webhooks enabled. Add a webhook for the intended workspace and channel, then copy the generated URL.

Uptime accepts secure Slack webhook URLs on hooks.slack.com whose path begins with /services/.

Treat the webhook as a credential. Anyone who has the complete URL can post to the connected Slack destination. Do not put it in source control, public documentation, screenshots, or support tickets.

Restrict the Slack app and channel according to your organization’s access policy. If the destination contains sensitive operational data, review guest membership and retention settings before sending tests.

Connect the destination

1. Open Integrations in the Uptime dashboard.
2. Select Connect integration, then choose Slack.
3. Give the destination a name based on its operational purpose.
4. Paste the incoming webhook URL.
5. Enable incident_confirmed, incident_resolved, or both.
6. Save the destination, then send a test message.

The webhook is encrypted at rest. Dashboard responses receive a safe credential hint rather than the full stored URL.

Choose event preferences

incident_confirmed is appropriate when the channel begins or coordinates response. incident_resolved closes the loop and helps downstream teams understand that service has recovered.

Use both for a primary incident channel. A stakeholder channel may need only confirmed and resolved state, while detailed investigation remains in the incident workspace.

Notification preferences are evaluated with integration enabled state. A disabled destination receives no new events until re-enabled.

Send and verify a test

A successful test should appear in the intended Slack channel and record its timestamp in Uptime. Check all of the following:

• the message arrived in the correct workspace and channel;
• the integration name is recognizable;
• links point to the expected application environment;
• no secret or internal target is shown unexpectedly;
• the delivery record reports success.

A failed test retains a sanitized error for troubleshooting. The UI should never display the stored webhook credential as part of an error.

Understand delivery evidence

Each matching incident event creates a delivery attempt. The incident timeline records the destination, event type, time, and outcome so responders can distinguish an incident-state problem from a notification problem.

When Slack does not receive an expected notification, check in this order:

1. Was the incident actually confirmed, or was it still an investigation?
2. Was the integration enabled at that time?
3. Did its event preferences include the emitted event?
4. Is there a delivery attempt in the incident timeline?
5. Did Slack reject the webhook or return a network error?
6. Was the Slack app or webhook removed from the workspace?

Do not repeatedly trigger test incidents to debug a credential. Use the integration’s test action and delivery history first.

Rotate the credential

Rotate the webhook after suspected disclosure, a Slack workspace change, or an access-policy event.

1. Create a replacement webhook in Slack.
2. Update the existing Uptime destination with the new URL.
3. Send a test and confirm delivery.
4. Revoke the previous webhook in Slack.
5. Record the rotation in the appropriate operational audit process.

Updating the credential preserves the destination’s identity and historical delivery records.

Disable or remove a destination

Disable the integration when delivery should pause but the configuration and history should remain available. Remove it when the destination is permanently retired.

Removing a destination stops future delivery. It does not delete historical incident events or previous delivery evidence. That separation protects the incident record from configuration changes made later.

Operational recommendations

• Keep at least one tested destination for critical services.
• Name destinations by purpose, not only provider.
• Review failed deliveries after incidents.
• Test after Slack workspace or channel ownership changes.
• Rotate credentials without posting the old or new URL in chat.
• Pair Slack with a clear alert policy; delivery cannot compensate for weak incident criteria.