Microservices and APIs workflow example, Getting started with Kestra

Keep your microservices and APIs honest with a lightweight, scheduled health check that pings any HTTP endpoint, inspects the response code, and pages your team on Slack the moment the service stops returning a healthy 200. It is the simplest possible uptime monitor expressed as declarative orchestration: no cron daemon to babysit, no shell script glued to a server, just a parameterized flow you can clone across every environment you run.

How it works

1. The http_request task (io.kestra.plugin.core.http.Request) sends an HTTP request to the server_uri input and captures the response. It runs with options.allowFailed: true so a non-2xx response does not abort the flow before you can react to it.
2. The check_status task (io.kestra.plugin.core.flow.If) branches on the condition {{ outputs.http_request.code != 200 }}.
3. If the status is not 200, the server_unreachable_alert task (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) posts a "server is down" message to the slack_webhook_uri.
4. Otherwise, the healthy task (io.kestra.plugin.core.log.Log) records that the server is responding normally.
5. The disabled daily trigger (io.kestra.plugin.core.trigger.Schedule) shows how to run the check automatically every morning at 09:00 with the cron 0 9 * * *.

What you get

• A reusable uptime probe for any REST API, website, or microservice.
• Conditional alerting that only notifies Slack on failure, avoiding noise.
• Parameterized server_uri and slack_webhook_uri inputs for instant reuse across dev, staging, and production.
• A ready-to-enable schedule so the check runs hands-free.

Who it's for

• Platform and SRE teams wanting a quick synthetic monitor without standing up new infrastructure.
• Backend engineers who need a starter template for endpoint health checks.
• Anyone learning Kestra who wants a clear, end-to-end example of HTTP, branching, and notifications.

Why orchestrate this with Kestra

A bare cron job can hit a URL, but it cannot branch on the result, retry on transient errors, alert on failure, or give you searchable execution history and lineage. Kestra turns the check into a declarative YAML flow with event and schedule triggers, built-in retries, full execution logs, and conditional logic, all observable from one UI. You replace a brittle script plus a separate alerting hack with a single versioned definition.

Prerequisites

• A running Kestra instance.
• A reachable HTTP endpoint to monitor (the server_uri input).
• A Slack Incoming Webhook URL for the channel that should receive alerts (the slack_webhook_uri input).

Secrets

This starter flow passes the webhook through the slack_webhook_uri input for easy demos. For production, store the webhook as a Kestra secret and reference it with {{ secret('SLACK_WEBHOOK_URI') }} instead of a plaintext default.

Quick start

1. Add the flow to your namespace.
2. Set the server_uri input to the endpoint you want to watch.
3. Set the slack_webhook_uri input to your real Slack Incoming Webhook URL.
4. Run it once and confirm the healthy log fires for a live endpoint.
5. Point it at an unreachable URL to verify the Slack alert path.
6. Remove disabled: true from the daily trigger to run the check every day at 09:00.

How to extend

• Probe multiple endpoints by looping over a list of URIs with io.kestra.plugin.core.flow.ForEach.
• Tighten the health rule by also checking response body content or latency, not just the status code.
• Add retries with backoff on http_request to ignore brief blips.
• Escalate beyond Slack: open a PagerDuty incident, send an email, or create a ticket on failure.
• Increase the schedule frequency (for example every five minutes) for tighter monitoring.

Links

• Slack plugin documentation
• Orchestrate Slack with Kestra