Monitor Multiple Websites and Send Instant Downtime Alerts via Slack and Email

Run lightweight, fully programmable website uptime monitoring directly inside Kestra. This blueprint polls a configurable list of URLs every 5 minutes, performs concurrent HTTP health checks, tracks each site's last known status in the KV store, and fires instant Slack and email alerts when a site goes down or recovers. It replaces standalone uptime tools (Pingdom, UptimeRobot, StatusCake) with a declarative YAML workflow that lives next to the rest of your orchestration, with full execution history, retries, and observability built in.

How it works

1. A io.kestra.plugin.core.trigger.Schedule trigger (every_5_minutes, cron */5 * * * *) launches the flow on a 5 minute cadence.
2. check_sites (io.kestra.plugin.core.flow.Loop) iterates over the websites input array with a concurrencyLimit of 5, so multiple URLs are probed in parallel.
3. For each URL, http_check (io.kestra.plugin.core.http.Request) issues a GET with allowFailed: true, a 10 second connect timeout and a 15 second read timeout.
4. get_previous_status (io.kestra.plugin.core.kv.Get) reads the prior UP or DOWN value from the KV store using a key derived from the URL, with errorOnMissing: false for first runs.
5. is_down (io.kestra.plugin.core.flow.If) flags the site as down when the response code is >= 400 or null. On a failure it persists DOWN via io.kestra.plugin.core.kv.Set, then sends a red alert through io.kestra.plugin.slack.notifications.SlackIncomingWebhook and an HTML email through io.kestra.plugin.email.MailSend (SMTP on port 465).
6. On a healthy response it stores UP and, if the previous status was DOWN, posts a green recovery message to Slack to close the incident loop.

What you get

• Parallel HTTP health checks across an arbitrary list of URLs, configurable per execution.
• Per-site state machine (UP, DOWN, recovery) backed by the Kestra KV store, so you do not get spammed on every poll.
• Instant Slack alerts with URL, status code, and UTC timestamp.
• HTML email alerts via any SMTP server for on-call rotations or shared inboxes.
• Recovery notifications when a previously down site comes back online.
• Full execution history, logs, and retry policy for every probe inside Kestra.

Who it is for

• Startups and SaaS teams that want uptime monitoring without paying for a dedicated SaaS tool.
• DevOps and platform teams that already run Kestra and want monitoring co-located with their pipelines.
• Freelancers and agencies managing multiple client sites from a single workflow.
• SRE teams that need custom alerting logic, like alerting only after N consecutive failures or branching by environment.

Why orchestrate this with Kestra

A cron job with curl can ping a URL, but it cannot remember state, fan out in parallel, deduplicate alerts, or send a recovery message when a site comes back. Kestra adds an event-driven Schedule trigger, durable KV state, declarative YAML, automatic retries, structured outputs, and full lineage across every probe and every alert. The same flow can be triggered ad hoc, on a schedule, or from a webhook, and every run is auditable from the UI.

Prerequisites

• A Kestra instance (OSS or Enterprise) with outbound network access to the target websites.
• A Slack Incoming Webhook URL for the alert channel.
• An SMTP relay (Gmail, SES, Mailgun, Postfix) that accepts TLS connections on port 465.

Secrets

Configure the following secrets in Kestra before running the flow:

• SLACK_WEBHOOK_URL: Slack Incoming Webhook URL used for both downtime and recovery alerts.
• ALERT_EMAIL_FROM: From address for outbound alert emails.
• ALERT_EMAIL_TO: Destination address (or comma separated list) for alert emails.
• SMTP_HOST: SMTP server hostname.
• SMTP_USERNAME: SMTP authentication username.
• SMTP_PASSWORD: SMTP authentication password or app password.

Quick start

1. Add the required secrets in your Kestra instance.
2. Copy this blueprint into a namespace such as company.team.
3. Edit the websites input default list, or pass a custom list per execution.
4. Run the flow once manually to seed the KV store and verify Slack and email delivery.
5. Enable the every_5_minutes schedule trigger to start continuous monitoring.

How to extend

• Alert only after N consecutive failures by storing a counter in KV instead of a boolean.
• Add a Postgres or BigQuery Query task to log every probe for historical SLA reporting.
• Escalate to PagerDuty or Opsgenie after repeated failures using their HTTP APIs.
• Check SSL certificate expiry on the same pass by parsing the response headers.
• Branch alerts by environment, owner, or severity using flow labels and the If task.
• Validate response body content (status JSON, expected substring) in addition to the status code.

Links

• HTTP plugin docs: https://kestra.io/plugins/core
• Slack plugin docs: https://kestra.io/plugins/plugin-slack
• Email plugin docs: https://kestra.io/plugins/plugin-email
• Slack orchestration overview: https://kestra.io/orchestration/slack