New to Kestra?
Use blueprints to kickstart your first workflows.
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.
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.
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.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.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.report_seeding posts the totals to Slack through io.kestra.plugin.slack.notifications.SlackIncomingWebhook.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.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.service, environment, dashboard_sample) on every seeded execution, ready for any label-driven chart you build next.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.
service and environment labels).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.service and environment labels - time series, KPIs, and tables should already show the service/environment mix.services, environments, and samples_per_combination to change the shape of the data, then re-seed.run_sample at a different flow (flowId) to seed with real pipeline executions instead of the built-in child mode.scheduleDate offset per iteration so charts cover past days, not just "now".team, region, tier - by extending the plan items and the labels map.