Scheduling a workflow every morning
A practical workshop for the warehouse refresh must start at 06:00 daily. Build the smallest manifest, validate it, run it and read the result.
Context — the warehouse refresh must start at 06:00 daily
The task is currently manual and its assumptions are not recorded. Hydra turns it into files that can be reviewed and rerun.
Where things stand
- The current result is fragile. Its assumptions are split between tools, clicks and memory.
- Reruns are uncertain. The write mode or orchestration rule is not visible beside the data.
- Evidence is missing. A colleague cannot compare a declared rule with a concrete before and after state.
The question
How do you make schedule explicit in workflow.yaml and verify the resulting execution states?
- Keep jobs independently runnable
- Give every workflow step a unique name
- Validate the graph before execution
- Read every step status in the summary
The solution in one line
A small workflow.yaml, one validation command and one run with observable step states.
workflow.yaml jobs/ sales/ inventory/ publish/
Name the work the workflow will coordinate.
Steps
1. prepare the jobs and boundary
- Name the work the workflow will coordinate.
- Compare the file with the explanation in the workbench.
- Record the shown check before moving to the next step.
workflow.yaml jobs/ sales/ inventory/ publish/
2. declare schedule
- Write the trigger, steps and policy.
- Compare the file with the explanation in the workbench.
- Record the shown check before moving to the next step.
workflow:
version: "1.0"
name: schedule_workshop
description: "Scheduling a workflow every morning"
trigger:
type: schedule
cron: "0 6 * * *"
steps:
- name: load_sales
type: job
job: ./jobs/sales 3. validate the graph
- Catch missing jobs, duplicate names and invalid dependencies.
- Compare the file with the explanation in the workbench.
- Record the shown check before moving to the next step.
$ hdrctl workflow validate workflow.yaml ✅ Workflow valid: schedule_workshop Steps: 1
4. run the workflow
- Execute and follow step states.
- Compare the file with the explanation in the workbench.
- Record the shown check before moving to the next step.
$ hdrctl workflow run workflow.yaml Schedule: 0 6 * * * Next run: 06:00 Timezone: scheduler configuration
5. read the orchestration result
- Distinguish success, skip, retry and continuation.
- Compare the file with the explanation in the workbench.
- Record the shown check before moving to the next step.
Schedule: 0 6 * * * Next run: 06:00 Timezone: scheduler configuration
Expected result
- The workflow validates before execution.
- Schedule: 0 6 * * *
- The run summary explains every terminal state.
Reading the results
Read the summary as a graph, not a flat log. Cron says when; the scheduler timezone decides which 06:00 it means.
What the counters do—and do not—prove
They prove how many records entered and left this run. They do not replace checking the target schema, the business meaning of values or the reason a workflow step was skipped.
The rule to carry forward
Cron says when; the scheduler timezone decides which 06:00 it means.
Did we answer the question?
| objective | result | where |
|---|---|---|
| Configuration explicit | yes | the relevant YAML block |
| Safe rerun | yes | the destination or workflow policy |
| Observable result | yes | the command output and counters |
| Hidden manual rule | removed | the rule now lives in versioned text |
Before and after
- Before — the warehouse refresh must start at 06:00 daily requires a person to remember the order, options and checks.
- After — one reviewed manifest and one command produce the same observable result.
- What is really gained — The durable gain is the contract: a colleague can read the configuration, reproduce the run and challenge the assumptions.