Webhook icon
Script icon
Process icon
If icon
Loop icon
Subflow icon
SlackIncomingWebhook icon
Return icon
Sleep icon
Fail icon
Log icon

Seed Dashboard Sample Data with Labeled Executions

Populate Kestra dashboards with realistic sample executions: labeled child runs and a pass/fail mix, so new dashboards show real charts instead of empty states.

Categories
Core

A dashboard blueprint opened on a fresh instance shows nothing: no executions, no labels, no states, no durations - just empty frames that hide what the dashboard can do. This flow fixes that by generating the data itself. It plans a matrix of service and environment combinations, then loops a Subflow call that re-invokes this same flow in child mode, stamping every child execution with service, environment, and dashboard_sample labels. A deliberate mix passes and fails, and each child sleeps for a varied few seconds, so state and duration charts look like real traffic. The label scheme matches dashboards that group by service and environment, so any pipeline dashboard you deploy opens on live-looking charts instead of empty frames.

How it works

  1. plan_samples (io.kestra.plugin.scripts.python.Script on the io.kestra.plugin.core.runner.Process runner) expands services × environments × samples_per_combination into a deterministic list: every fourth sample is marked to fail and sleep varies from 2 to 6 seconds, so both the parent plan and child outputs always resolve from the same step.
  2. is_parent (io.kestra.plugin.core.flow.If) splits the two modes on the mode input: the parent fans out, the child produces exactly one sample and stops.
  3. In parent mode, seed_executions (io.kestra.plugin.core.flow.Loop) walks the plan and run_sample (io.kestra.plugin.core.flow.Subflow) re-invokes this flow with mode: child, binding the sample's values as inputs and setting service, environment, and dashboard_sample labels on the child execution. wait: true with transmitFailed: false keeps the seeder green even when a child fails on purpose.
  4. report_seeding posts the totals to Slack through io.kestra.plugin.slack.notifications.SlackIncomingWebhook.
  5. In child mode, sample_work (io.kestra.plugin.core.debug.Return) stands in for real work, sample_burn_time (io.kestra.plugin.core.flow.Sleep) varies the duration, and maybe_fail (io.kestra.plugin.core.flow.If) ends a deliberate share of samples through io.kestra.plugin.core.execution.Fail.
  6. The errors block alerts Slack if seeding itself breaks, and the seed_on_demand trigger (io.kestra.plugin.core.trigger.Webhook, keyed URL) lets CI or a button POST start a seeding run.

What you get

  • A dashboard that opens with realistic charts: per-service executions over time, success and failure KPIs, per-environment tables, and log counts.
  • Labels (service, environment, dashboard_sample) on every seeded execution, ready for any label-driven chart you build next.
  • A controllable failure ratio and duration spread from plain inputs - no data generators or SQL inserts.
  • One self-contained flow: no companion child flow to install, because the seeder re-invokes itself in child mode.

Who it's for

  • Authors of dashboard and App blueprints who need demo data that makes the UI tell a story.
  • Teams evaluating Kestra dashboards who want to see state mixes and label splits before wiring real pipelines.
  • Solution engineers preparing demos and workshops on fresh instances.

Why orchestrate this with Kestra

Creating dozens of labeled executions is exactly what orchestration is for: a loop of subflow calls gives each sample its own execution id, state, labels, logs, and lineage - the very rows dashboards query. Doing this with the API by hand means twenty curl calls and manual label maps; doing it as a flow means one trigger, an execution history proving what was seeded, inputs that change the shape of the data, and a repeatable fixture for demos. Because the flow re-invokes itself, there is no second blueprint to keep in sync.

Prerequisites

  • A running Kestra instance (optionally with a dashboard grouping executions by the service and environment labels).
  • Permission to create executions of this flow in its namespace.
  • A Slack incoming webhook for the seeding summary and failure alerts.

Secrets

  • SEED_WEBHOOK_KEY: key guarding the webhook trigger URL; pick any random string.
  • SLACK_WEBHOOK_URL: Slack incoming webhook URL for seeding summary and failure alerts.

Quick start

  1. Add both secrets to the Kestra namespace.
  2. Deploy this flow on its own - no companion files are needed.
  3. Execute the flow once with the defaults (12 samples, 3 failing on purpose) or POST to the webhook URL.
  4. Open a dashboard grouped by the service and environment labels - time series, KPIs, and tables should already show the service/environment mix.
  5. Adjust services, environments, and samples_per_combination to change the shape of the data, then re-seed.

How to extend

  • Repoint run_sample at a different flow (flowId) to seed with real pipeline executions instead of the built-in child mode.
  • Seed historical data by adding a scheduleDate offset per iteration so charts cover past days, not just "now".
  • Emit additional label dimensions - team, region, tier - by extending the plan items and the labels map.
  • Swap the Slack summary for a Discord webhook or drop it entirely in demo environments.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.