Qlik Cloud App Reload Failure Gate

A Qlik Cloud app's own reload history page shows the last run if someone opens it, but nothing pages anyone when a dashboard quietly starts reloading three times slower than usual, or fails outright overnight with nobody watching. This blueprint uses io.kestra.plugin.qlikcloud.apps.Reload to reload a named app and wait for its terminal status, classifies the result by both outcome and duration, and alerts on anything but a clean bill of health.

This blueprint was created by Mohit Jeswani.

How it works

1. reload_app (io.kestra.plugin.qlikcloud.apps.Reload, wait: true) triggers a full reload of app_id and polls until it reaches SUCCEEDED, FAILED, CANCELED, or EXCEEDED_LIMIT. The task only ever returns an Output on SUCCEEDED; any other terminal status, or a timeout past maxDuration, makes it throw instead. allowFailure: true catches that so the flow can still classify and alert rather than failing outright.
2. evaluate (io.kestra.plugin.core.output.OutputValues) computes the reload's duration from its own startTime/endTime and compares it to max_reload_minutes. Because reload_app only returns on success, a missing output already means CRITICAL; a present output is classified SLOW or OK purely on duration.
3. route (io.kestra.plugin.core.flow.If):
   • compliant: logs the measured duration.
   • alert: posts the severity and either the duration or "failed or timed out" to Slack.
4. summary logs the status, duration and severity, closing the governance cycle.
5. errors alerts Slack if the flow itself fails outside the handled cases.

What you get

• Outright failure/timeout (CRITICAL) and slow-but-successful (SLOW) treated as genuinely different severities, computed from the reload's own timestamps, not a guess.
• A Slack alert the moment a reload breaches your own duration budget, instead of only Qlik Cloud's fixed ~3 hour ceiling.
• A full execution history of every reload's outcome and duration, not just the last one visible in the Qlik Cloud console.

Who it's for

• BI and data platform teams running Qlik Cloud who want a critical app's reload watched for both outright failure and duration creep, without a second monitoring stack.
• Teams evaluating the Qlik Cloud plugin who want a worked example of apps.Reload used as a monitored gate, distinct from a plain fire-and-forget trigger.

Why orchestrate this with Kestra

Triggering a reload from Qlik Cloud's own UI or API answers one moment in time; it does not decide a cadence, classify the result by both outcome and duration, or notify anyone. Kestra supplies the schedule, the OK/SLOW/CRITICAL classification as a first-class branch, and an execution history that shows exactly when an app's reload started failing or slowing down.

Prerequisites

• A Qlik Cloud tenant with an app to monitor, and reload permission on it.
• A Qlik Cloud API key (tenant Management Console > Identity & access > API keys) or a pre-obtained OAuth 2.0 access token.
• A Slack incoming webhook URL.

This flow calls the Qlik Cloud REST API directly over HTTPS; there is no official local Qlik Cloud emulator, so reload_app cannot be exercised against a local Docker container, and it genuinely reloads data on every run. Validate against a non-production app first.

Secrets

• QLIK_API_KEY: the Qlik Cloud API key or OAuth access token used by reload_app. In Kestra OSS, provide it as the base64-encoded environment variable SECRET_QLIK_API_KEY.
• 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
tenant_url	https://<your-tenant>.<region>.qlikcloud.com	Qlik Cloud tenant root URL
app_id	<your-qlik-app-id>	App to reload and monitor
max_reload_minutes	30	Duration past which a successful reload is SLOW
max_wait_duration	PT1H	This gate's own wait ceiling, separate from Qlik's ~3h cap

Outputs

• {{ outputs.reload_app.status }}: SUCCEEDED when present (the only case reload_app returns normally).
• {{ outputs.reload_app.startTime }} / .endTime / .duration: timing of the reload.
• {{ outputs.reload_app.logUri }}: internal storage URI of the reload log, when available.
• {{ outputs.evaluate.values.severity }}: OK, SLOW, or CRITICAL.

Pitfalls

• This flow triggers a real reload every time it runs. Unlike a passive status poll, it starts real work on Qlik Cloud's side on every execution, scheduled or manual. Do not point app_id at an app where an extra, unplanned reload is unsafe or expensive.
• A timeout does not return a distinct status. reload_app throws the same way on a timeout as on an outright FAILED result; both are classified CRITICAL here, not distinguished from each other in the Slack alert.
• reattach defaults to true. A worker restart or manual Restart of the same execution adopts the already-triggered reload instead of starting a duplicate one. That is usually what you want for a scheduled gate; set it to false only if you specifically need a fresh reload on every retry.
• A reload already in progress for the app returns a 429, which this task raises as a clear error rather than retrying - back-to-back scheduled runs faster than the app's own reload time will fail, not queue.

Quick start

1. Add the QLIK_API_KEY and SLACK_WEBHOOK_URL secrets.
2. Set tenant_url and app_id to a real, non-production app.
3. Run the flow manually and confirm compliant logs a duration.
4. Lower max_reload_minutes below the app's real reload time to confirm alert fires with SLOW.
5. Enable the hourly trigger only once you are certain a reload on every run is acceptable for this app.

How to extend

• Target by spaceName + appName instead of appId (both supported directly on Reload) when the app ID is not known ahead of time.
• Loop over several app_id values with io.kestra.plugin.core.flow.Loop to watch a whole space's apps in one scheduled run, with concurrencyLimit: 1 to avoid triggering every app's reload at once.
• Read outputs.reload_app.logUri in the alert branch to attach or link the actual reload log when a reload fails, not just the status.

Links

• Qlik Cloud plugin: https://kestra.io/plugins/plugin-qlikcloud
• Qlik Cloud Reloads API: https://qlik.dev/apis/rest/reloads/
• Slack incoming webhooks: https://api.slack.com/messaging/webhooks