New to Kestra?
Use blueprints to kickstart your first workflows.
Kestra recovery subflow that resets a KV-backed system state to healthy. Called by a LoopUntil self-healing loop whenever a health check fails, simulating an automated restart.
id: reset-flaky-system
namespace: company.team
description: |
Self-recovery subflow. Called from the recovery loop in the
self-healing-recovery-loop blueprint whenever the health check in
flaky-system-health-check reports a failure. It flips the
flaky_system_status KV entry back to a healthy status code, simulating a
service restart, so the next loop iteration succeeds.
tasks:
- id: reset_flaky_system_status
type: io.kestra.plugin.core.kv.Set
description: Flip the simulated system state back to healthy.
key: flaky_system_status
value: "200"
- id: log_reset
type: io.kestra.plugin.core.log.Log
message: "flaky_system_status KV entry reset to 200, simulated system restarted"
This is the recovery action of a self-healing orchestration pattern. When a parent loop detects that a dependency is unhealthy, it does not page a human first; it calls this subflow, which performs the corrective action and hands control straight back to the loop for another health check. Here the "restart" is simulated by flipping a KV entry, which keeps the blueprint runnable anywhere, but the structure is exactly what you would use to bounce a real service.
reset_flaky_system_status task (io.kestra.plugin.core.kv.Set) writes 200 to the flaky_system_status KV entry. The companion health-check flow reads this same entry and calls https://httpbin.org/status/<value>, so after the reset the next probe returns HTTP 200.log_reset task (io.kestra.plugin.core.log.Log) records that recovery ran, giving the parent execution an auditable trace of every self-healing action.The parent flow invokes this blueprint through io.kestra.plugin.core.flow.Subflow with wait: true and transmitFailed: false, so the loop pauses until recovery completes and is never poisoned by a recovery hiccup.
Remediation logic buried in a monitoring tool's webhook or a cron script is invisible until it misfires. As a Kestra subflow, every recovery is a first-class execution with its own logs, duration, and revision history. The KV store gives flows a shared, durable state without standing up a database, and the subflow contract means you can swap the simulated reset for a real restart (Kubernetes rollout, systemd unit, cloud API call) without touching the parent loop at all.
company.team namespace (built in, no plugin install needed).No secrets are required for the simulated reset. If you replace it with a real restart, store credentials such as a kubeconfig token or cloud API key as secrets and reference them with {{ secret('NAME') }}.
company.team namespace.flaky_system_status KV entry to 500 to simulate a broken system.200.io.kestra.plugin.kubernetes.kubectl.PodDelete to bounce a pod or an HTTP call to a service's restart endpoint.log_reset so on-call sees that self-healing fired even when no human action was needed.service_name to make one recovery flow serve many systems.