Monitor an HTTP endpoint and send a Slack alert when it is unhealthy

Uptime monitoring should not depend on someone remembering to refresh a page. This blueprint turns any URL into a scheduled HTTP health check: Kestra calls the endpoint, inspects the response code, and pages your team on Slack the instant it stops returning a healthy 200. It is a lightweight, fully declarative synthetic monitor for APIs, websites, webhooks, and internal services, with no agent to install and no separate alerting stack to maintain.

How it works

1. A io.kestra.plugin.core.trigger.Schedule trigger fires every day at 09:00 (cron: 0 9 * * *).
2. The api task (io.kestra.plugin.core.http.Request) sends an HTTP request to the uri input, which defaults to https://kestra.io.
3. A io.kestra.plugin.core.flow.If task evaluates the condition {{ outputs.api.code != 200 }}.
4. If the status is not 200, the unhealthy task (io.kestra.plugin.core.log.Log) records the response body, and send_slack_alert (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) posts a message that the server is down.
5. Otherwise, the healthy task logs that everything is fine.

What you get

• Scheduled, hands-off uptime checks for any HTTP endpoint.
• Instant Slack notifications when an endpoint returns a non-200 code.
• The full response body captured in logs for fast triage.
• A single declarative YAML file you can version, review, and reuse.

Who it's for

• Platform and SRE teams running synthetic monitoring on critical services.
• Backend engineers watching their own APIs and webhooks.
• Data and ops teams confirming an upstream service is reachable before a pipeline runs.

Why orchestrate this with Kestra

A bare curl in cron has no memory and no escalation path. Kestra adds the event-driven Schedule trigger, automatic retries, full execution history and lineage for every check, and conditional branching that routes failures straight to Slack, all from declarative YAML. The endpoint being monitored has no scheduler or alerting of its own, so Kestra supplies the recurring cadence, the pass/fail logic, and the notification fan-out in one place.

Prerequisites

• A running Kestra instance.
• A reachable HTTP endpoint to monitor.
• A Slack Incoming Webhook URL for your alerts channel.

Secrets

• SLACK_WEBHOOK: the Slack Incoming Webhook URL used by send_slack_alert.

Quick start

1. Add the SLACK_WEBHOOK secret to your Kestra instance.
2. Import this flow into a namespace.
3. Set the uri input to the endpoint you want to watch.
4. Trigger an execution manually to confirm the healthy and unhealthy paths.
5. Let the daily schedule take over, or adjust the cron to your needs.

How to extend

• Change the cron to run every few minutes for near-real-time monitoring.
• Treat any 2xx code as healthy, or assert on response body content or latency.
• Loop over a list of URLs to monitor a fleet of services in one flow.
• Swap or add notification channels (email, PagerDuty, Microsoft Teams) alongside Slack.
• Add retries on the api task to avoid alerting on a single transient blip.

Links

• HTTP plugin documentation
• Slack plugin documentation