HTTP and Slack: Scheduled API Health Probe With Escalation Template

A scheduled probe that calls one of your endpoints on a fixed cadence and pages a Slack on-call channel only after several consecutive failures, so transient blips do not wake anyone.

What It Builds

This Spojit template runs a Schedule trigger every few minutes, uses a Connector node on the http connector (http-get) to probe a health endpoint, and feeds the result into a Condition node. A small running failure count is kept between runs, and a second Condition escalates to a Slack channel with send-message only once the endpoint has failed a set number of times in a row. When the endpoint recovers, the count resets and a recovery message is posted. The result is flap-resistant monitoring: one alert per real outage, not one per hiccup.

The Prompt

Paste this into Miraxa and it builds the workflow, connecting the tools for you:

Build a workflow on a Schedule trigger that runs every 5 minutes. Add a Connector node on the http connector that does an http-get on https://api.example.com/health and treats a 200 response as healthy and anything else (or a request error) as a failure. Keep a consecutive-failure counter that increments on each failure and resets to zero on success. Add a Condition node so that when the failure count reaches 3 in a row, a Connector node on Slack posts to the #on-call channel with send-message saying the endpoint is down, the failing status, and the time. When the endpoint recovers after having been down, post a recovery message to the same channel.

Connectors Used

Schedule trigger - runs the probe on a fixed cadence (5-field cron plus IANA timezone, for example */5 * * * *).
http connector - http-get probes your endpoint; works against any public REST or health URL, with an API key passed in the Authorization header if the endpoint needs one.
Slack connector - send-message posts the down and recovery alerts to your on-call channel.

Customize It

The obvious knobs are in the prompt: change the cron to probe more or less often, swap the health URL for your own endpoint, set the failure threshold (raise it past 3 for a noisier endpoint, lower it for a critical one), and change #on-call to your team channel. You can also tighten the success rule (for example, require the body to contain "status":"ok" rather than just a 200 status) by saying so in the prompt before you build.

Tips

Keep both Connector nodes in Direct mode: the probe and the Slack post are single, predictable tool calls, so you avoid AI credit cost and get deterministic behavior.
The consecutive-failure threshold is what makes this flap-resistant. Set it so a single slow or dropped request never pages anyone: a threshold of 3 over a 5-minute cadence means the endpoint must be unhealthy for roughly 15 minutes before Slack fires.
Post a recovery message too, not just a down alert, so the channel always reflects the current state and nobody chases an outage that has already cleared.

Common Pitfalls

A non-200 status is not the only failure: a timeout or connection error from http-get should also count as a failure, or a hung endpoint will look healthy. Make sure both paths increment the counter.
Without the counter reset on success, the count keeps climbing and you get a stale alert long after recovery. Confirm the success branch sets the count back to zero.
Pick the Slack channel in the connector field, not as free text in the message body, so send-message targets the right place every run.