Health Check a Flaky System and Report Status as a Flow Output

Turn a flaky HTTP call into a signal instead of a crash. This Kestra blueprint is the health-check building block of a self-healing pattern: it probes an endpoint exactly once, refuses to fail even when the endpoint returns a 5xx, and reports the real outcome through a single typed flow output. A parent flow running io.kestra.plugin.core.flow.LoopUntil can then evaluate that output and decide whether to retry, trigger recovery, or declare the system healthy.

How it works

1. The get_flaky_system_status task (io.kestra.plugin.core.kv.Get) reads the flaky_system_status KV entry, which simulates the current state of the target system (a value of 500 means unhealthy, 200 means healthy). errorOnMissing: true makes the flow fail fast if the entry was never seeded.
2. The call_flaky_system task (io.kestra.plugin.core.http.Request) calls https://httpbin.org/status/<code> with that value. The key detail is options.allowFailed: true, which makes a non-2xx response complete normally instead of failing the task.
3. The flow-level status output evaluates outputs.call_flaky_system.code == 200 and returns the string success or failure.

The reason this lives in its own flow rather than inline in the parent: LoopUntil conditions can only see outputs of their direct children, so wrapping the probe in a subflow gives the loop a stable, one-level-down expression such as {{ outputs.attempt_flaky_call.outputs.status }}.

What you get

• A probe that never poisons the parent execution with a spurious FAILED state.
• A single status output with exactly two values, easy to branch on with runIf.
• A reusable health-check component you can call from any flow via io.kestra.plugin.core.flow.Subflow.
• A KV-backed simulation of an unreliable dependency, useful for demos and chaos-style testing.

Who it's for

• Platform and SRE engineers building self-healing orchestration around unreliable services.
• Data engineers who poll upstream APIs that flap during deploys or maintenance windows.
• Anyone composing LoopUntil recovery loops that need a clean boolean-like signal from a child execution.

Why orchestrate this with Kestra

Shell scripts that wrap curl and grep the exit code lose history the moment they finish. In Kestra, every probe is a full execution with logs, timings, and the resolved KV value, so you can see exactly what the system returned on each attempt. allowFailed is a first-class task option rather than a bash || true hack, typed flow outputs replace fragile stdout parsing, and the subflow boundary makes the health check reusable across every flow that needs it.

Prerequisites

• A Kestra instance with outbound HTTPS access to httpbin.org (or your real endpoint).
• A flaky_system_status KV entry in the namespace. The parent blueprint seeds it with 500; you can also set it manually under Namespaces, KV Store.

Secrets

No secrets are required. If your real health endpoint needs auth, add a header such as Authorization: "Bearer {{ secret('HEALTHCHECK_TOKEN') }}" to the call_flaky_system task.

Quick start

1. Import this flow into the company.team namespace.
2. Create the flaky_system_status KV entry with value 500 or 200.
3. Run the flow and check the status output on the execution's Outputs tab.
4. Flip the KV value and run again to see the output change without any task ever failing.

How to extend

• Point uri at a real readiness endpoint and drop the KV lookup entirely.
• Return richer outputs, for example the latency via outputs.call_flaky_system.headers or the response body for deeper diagnostics.
• Add a retry block to the HTTP task to absorb pure network blips before reporting failure.
• Call it from any flow with io.kestra.plugin.core.flow.Subflow and wait: true, then branch on outputs.<task_id>.outputs.status.

Links

• Self-healing recovery loop (parent flow): https://kestra.io/blueprints/self-healing-recovery-loop
• Reset subflow that heals the system: https://kestra.io/blueprints/reset-flaky-system
• Automated RCA on SLA breach: https://kestra.io/blueprints/sla-breach-root-cause-analysis