Skip to main content
Incident alerting

Alert the right people when a client website needs attention

Create reusable channels and route each client-site alert rule to the people and tools that should know first.

No credit card required during the trial period.

New alert rule

Route slow response incidents to the right channels.

Setup

Trigger

Response time

> 2,000 ms

Recovery

2 healthy checks

auto-resolve

Notify channels

3 selected
Engineering Slack
PagerDuty primary
Ops mailbox
Rule armed for downctl.com ACTIVE

Alert Triggered

MyApp

https://myapp.com

Condition

Response time is greater than 2,000 ms

Observed value

2,842.0 ms

Triggered at

Jul 26, 2026 12:43:18 UTC

Monitor details

API checkout health

GET https://myapp.com/api/checkout/health

Expected response time below threshold.

You are receiving this because an alert rule on DownCTL matched. Manage your alert rules in the site dashboard.

MyApp Status

Post mortem published

API latency incident post mortem

MyApp Status

This is a simulated public post mortem for testing.

We've published a full incident report including root cause analysis, timeline, and steps we're taking to prevent this from happening again.

You're receiving this because you subscribed to status updates for MyApp Status. Unsubscribe

What DownCTL alerts on

Alerting rules connect monitor failures to the right people and channels across uptime, SSL, DNS, API, infrastructure, cron, crawl, and error checks.

Downtime

Slow response

SSL expiration

DNS issues

Domain expiration

Server metrics

Application errors

Cron check-in failures

API assertion failures

Crawl and sitemap findings

Why it matters

Monitoring creates value when it reaches the right responder quickly. Alert rules make each signal actionable instead of just observable.

Monitoring only helps when the right person knows quickly

Different teams need different channels

Rules should map to real operational workflows

A fixed threshold across every site causes false alarms for some and missed warnings for others

How it works in DownCTL

Incident alerting is the connective tissue across the client website operations stack.

  1. 1 Create reusable alert channels
  2. 2 Add alert rules per site
  3. 3 Choose the trigger and threshold
  4. 4 Route alerts to one or more channels
FAQ

Common questions

What alert channels does DownCTL support?

DownCTL supports email, webhooks, Slack, Teams, PagerDuty, Discord, Opsgenie, Telegram, Pushover, and ntfy.

Can one rule notify multiple channels?

Yes. Alert rules can target one or more channels.

Can I create alerts per site?

Yes. Alert rules are configured around the monitored site and its signals.

Can alerts become public incidents?

Alerts can be published into public incidents and trigger public status communication.

Can I change how many failed checks it takes to open an incident?

Yes. Incident policies can be tuned at the workspace level with per-site overrides for each monitor type, so one client site can stay strict while another tolerates a brief blip.

Can I see whether an alert was actually delivered?

Yes. Every notification route keeps a per-channel delivery record, so you can see exactly who was notified, through which channel, and whether the delivery succeeded.

Start monitoring with DownCTL

Start your free trial and bring client-site uptime, website health, alerts, and status pages into one place.

14-day free trial · No credit card required · Cancel anytime