Send Website Downtime Alerts to Discord, Slack and More

If your website goes down, the useful alert is the one that reaches the place you already watch. AlertsDown's additional integrations let customers on any paid plan route downtime notifications to chat, push, and incident-management destinations from one monitor setup.

Each destination is configured once as a labeled URL, and AlertsDown can hand a confirmed downtime alert to that service. This guide is for developers and small SaaS teams that want a practical alert path without building a separate integration for every destination. It explains the setup flow, the URL formats that AlertsDown accepts, and the limits to understand before you rely on a notification during an incident.

Which destinations are available?

AlertsDown currently reviews and enables thirteen destination schemes on every paid plan:

• Discord (discord://)
• Slack (slack://)
• Google Chat (gchat://)
• Webex (wxteams://)
• Hosted, token-authenticated ntfy (ntfys://)
• Jira (jira://)
• SIGNL4 (signl4://)
• PagerTree (pagertree://)
• Microsoft Teams Workflows (workflows://)
• PagerDuty (pagerduty://)
• Opsgenie (opsgenie://)
• Pushover (pover://)
• Pushbullet (pbul://)

Opsgenie is retained for existing workflows, but Atlassian is retiring it on April 5, 2027, so Jira is recommended for new setups. These are the destinations supported by this AlertsDown configuration. Use only the schemes shown in the AlertsDown contact form. Generic webhooks, custom plugins, and other services are outside this release.

Set up an integration contact in AlertsDown

The setup takes place in your AlertsDown dashboard:

1. Choose any paid plan. Additional integrations are included with Indie Builders, Saas Builders, and Founding Builders, and your plan's notification quota still applies.
2. Open My Contacts and choose Add Contact.
3. Select More..., give the destination a friendly label such as Operations Discord, and enter one destination URL.
4. Save the contact, then use the available test action to check the destination.
5. Open the monitor you want to protect and attach the saved contact to it.

AlertsDown stores the destination as a protected secret and shows the label and service metadata later. Keep the original URL private: it may contain a token, key, or webhook credential. Do not paste it into tickets, screenshots, or support messages.

Chat webhook URL examples

If you copy a standard incoming webhook URL from Discord, Slack, Google Chat, or Webex, AlertsDown can convert the supported form into a destination scheme before sending it to the backend. These placeholders show the shape without exposing a real credential:

https://discord.com/api/webhooks/123456789012345678/REPLACE_WITH_TOKEN

becomes a Discord destination URL such as:

discord://123456789012345678/REPLACE_WITH_TOKEN

Likewise, a Slack webhook shaped like:

https://hooks.slack.com/services/T12345678/B12345678/REPLACE_WITH_TOKEN

is converted to:

slack://T12345678/B12345678/REPLACE_WITH_TOKEN

Google Chat webhooks from chat.googleapis.com and Webex incoming webhooks from webexapis.com or api.ciscospark.com are normalized in the same way. The placeholders are examples only. Use the real URL from the provider when you create the contact, and treat it like a password. For ntfy and incident-management services, follow the destination provider's documentation to construct the scheme-specific URL, then paste that one URL into AlertsDown. Hosted ntfy contacts require a token-authenticated ntfys://token@ntfy.sh/topic URL.

Use one destination per monitor

An integration contact represents one destination URL. AlertsDown accepts one destination URL when you create the contact, and a monitor can reference only one integration contact. If you need different destinations, save separate labeled contacts and use the one that fits each monitor. You can combine that one route with other supported native channels, subject to the notification quota and plan rules.

This separation makes ownership and testing clearer. You can test the Discord contact without exposing the PagerDuty credential, and remove one route without changing the others. It also avoids relying on a multi-service URL that this release does not accept.

Quotas, delivery, and incident expectations

Additional integrations do not remove AlertsDown's plan limits. Your paid plan's notification quota, monitor limits, and any other plan rules continue to apply. Check the current pricing page before choosing a plan because limits and availability can change.

A successful test or dispatch means AlertsDown handed the message to the configured destination service. It does not guarantee that Discord, Slack, a paging provider, or a mobile push service will deliver it, display it immediately, or escalate it to another responder. Provider outages, invalid credentials, rate limits, muted channels, and device connectivity can all affect the final result.

For Jira, SIGNL4, PagerTree, and legacy Opsgenie, AlertsDown adds a stable incident alias so a recovery can resolve the alert created for that outage. A recovery is sent only when that same integration contact successfully delivered the downtime alert. Jira and Opsgenie recovery closes are handled directly by AlertsDown because the internal delivery service is deliberately stateless.

For a critical service, document who owns the destination and keep a second alert path that fits your incident process. Treat that as an operational choice, not as an automatic failover or guaranteed escalation.

Keep the configuration maintainable

Use labels that identify both the team and destination, such as Web on-call — Slack or Payments — PagerDuty. Test after creating a contact and again when credentials or provider settings change. Rotate provider credentials in the provider's own dashboard, then replace the protected contact in AlertsDown when necessary.

Finally, attach the contact only to monitors that need it. A focused route reduces noise and makes it easier to tell whether an alert was sent to the right destination. AlertsDown confirms downtime according to the monitor's normal check behavior; the integration contact is the delivery route after that monitoring decision.

View paid plans

Additional integrations are designed for teams that want Discord, Slack, paging, or push destinations beside their uptime monitors. Review the current limits and included channels on the pricing page, then choose any paid plan, create the labeled contact, and attach it to the monitor that matters most.