Clever Cloud Application State Drift Sentinel

An application that is supposed to be running does not page anyone when it quietly ends up in a different state, stopped by someone outside the usual deploy path, or left in a state nobody intended after a failed operation. Clever Cloud's own console shows the state if you open the application; it has no native alert for "this is not the state it should be in right now". This blueprint reads the state directly and compares it to what you declare expected.

How it works

1. get_application (io.kestra.plugin.clevercloud.applications.Get) fetches application_id's current state, along with its zone and instance configuration. Read-only; nothing is started, stopped, or redeployed. allowFailure: true covers an API or auth error without failing the flow outright.
2. evaluate (io.kestra.plugin.core.output.OutputValues) compares the actual state against expected_state. A failed fetch is also treated as a finding, same severity as a state mismatch.
3. route (io.kestra.plugin.core.flow.If):
   • compliant: logs that the state matches.
   • alert: posts the actual and expected state to Slack.
4. summary logs the actual state and severity, closing the governance cycle.
5. errors alerts Slack if the flow itself fails, for example an expired API token.

What you get

• A direct read of the application's real state, compared against what you declared it should be, not inferred from deploy logs or a dashboard someone has to open.
• A failed fetch and a genuine state mismatch both surface, but the alert text names which one actually happened.
• A record, in Kestra's execution history, of every check, not just the last console visit.

Who it's for

• Platform teams running production workloads on Clever Cloud who want a critical application's state watched between deploys, not just during them.
• Teams evaluating the Clever Cloud plugin who want a worked example of applications.Get used as a standing compliance check rather than a one-off lookup.

Why orchestrate this with Kestra

Clever Cloud reports the state; it does not decide what state is correct for a given application, compare it against that expectation, or notify anyone when they diverge. Kestra keeps expected_state as a flow input instead of institutional memory, turns a state check into a Slack page naming the actual and expected values, and keeps a full execution history of every run.

Prerequisites

• A Clever Cloud account (personal or organisation) with at least one application already deployed.
• A Clever Cloud API token (CC_API_TOKEN) with read access to the application.
• A Slack incoming webhook URL.

This flow calls the Clever Cloud API directly over HTTPS; there is no official local Clever Cloud emulator, so get_application cannot be exercised against a local Docker container. Run get_application manually once first to read your own application's real state value before setting expected_state, since the exact state strings an account reports were not independently confirmed against Clever Cloud's own API reference for this blueprint.

Secrets

• CC_API_TOKEN: the Clever Cloud API token used by get_application. In Kestra OSS, provide it as the base64-encoded environment variable SECRET_CC_API_TOKEN.
• SLACK_WEBHOOK_URL: used by alert and the errors block. In Kestra OSS, provide it as the base64-encoded environment variable SECRET_SLACK_WEBHOOK_URL.

Inputs

Input	Default	Purpose
organisation_id	empty	Organisation ID, empty uses the personal account
application_id	<your-app-id>	Application to watch
expected_state	SHOULD_BE_UP	The state value this application should currently report

Outputs

• {{ outputs.get_application.state }}: the application's current state.
• {{ outputs.get_application.zone }} / .instance / .deployUrl: additional application detail returned alongside state.
• {{ outputs.evaluate.values.severity }}: OK, DRIFT, or CRITICAL.

Pitfalls

• This blueprint does not assume any specific state string. expected_state is compared by exact, case-sensitive string equality against whatever applications.Get returns; confirm the real value for your account first rather than guessing one.
• A CRITICAL result (fetch failed) and a DRIFT result (fetch succeeded, state mismatched) are both routed to the same alert branch; read the Slack message's actual_state value to tell them apart; it reads unknown only on a failed fetch.
• organisationId left empty always targets the personal account's /self endpoint, even if the application actually lives in an organisation you also have access to; set it explicitly for an organisation-owned application.

Quick start

1. Add the CC_API_TOKEN and SLACK_WEBHOOK_URL secrets.
2. Run get_application once manually (or this whole flow with any expected_state) and read the real state value from outputs.get_application.state in the execution log.
3. Set expected_state to that real value and re-run to confirm compliant logs it.
4. Set expected_state to a different string to confirm alert fires with DRIFT.
5. Enable the hourly trigger once expected_state reflects the application's real, intended state.

How to extend

• Loop over several application_id values with io.kestra.plugin.core.flow.Loop to watch every critical application in an organisation in one scheduled run.
• Chain io.kestra.plugin.clevercloud.deployments.List after a DRIFT result to pull the most recent deployment and include its outcome in the Slack alert.
• Add a remediation branch that calls a redeploy or restart task, gated behind the auto_remediate/dry_run pair used elsewhere in this repo's guard blueprints, once you have confirmed the exact state transition that fixes the drift for your account.

Links

• Kestra Clever Cloud plugin documentation
• Clever Cloud API v2 reference
• Slack incoming webhooks