Where this course goes
Six sessions, one running artifact: Daybreak's nightly warehouse build, the 2am batch that Learn Data Pipelines assembled and Learn Streaming Data raced past. Today it is one crontab file. By session 6 it is a governed DAG with retries, rerun-safe tasks, a tested backfill path and an alert that fires before anyone opens the dashboard - and you will have watched every upgrade earn its keep across the same thirty nights.
★ What you walk out with: the punctual-liar frame - on time and correct are different promises - plus a precise list of what clock-based scheduling actually guarantees, and the thirty-nights simulator you will upgrade lever by lever for five more sessions.
What cron actually promises 6 min live
Cron is not a lesser orchestrator. It is a clock with an execute button, and the man page is admirably clear about which one it is.
Live The contract, straight from the man page 4 min ▶
The crontab(5) man page defines the entire deal: commands are executed when the minute, hour and month fields match the current time, and cron examines its entries every minute. That is the whole promise. Read the page looking for the words "depends", "retry" or "overlap" and you will not find them - not because the docs are lazy, but because cron defines no such features. It is a clock, and clocks do not check your work.
- No dependencies. The 2:30 clean job fires at 2:30 whether the 2:00 extracts succeeded, failed, or are still running.
- No retries. A task that dies, died. Tonight's run is over; see you tomorrow.
- No overlap protection. If tonight's job is still running when tomorrow's fires, both run.
- No downtime catch-up. A run missed while the box was down is simply gone - that gap is what anacron exists to fill.
The man page even documents the clock biting back: jobs scheduled inside the daylight-saving "missing hour" never run, and times that occur twice run twice. Teams discover this exactly two mornings per year, both times by surprise.
Self-study Why cron is still everywhere, and still fine 3 min ▶
None of this makes cron bad. A single job with no upstream - a log rotation, a certificate renewal, a cache warm - needs exactly a clock, and adding an orchestrator to it is ceremony. Cron even quietly compensates for small clock adjustments: after a jump of under three hours, skipped jobs run immediately and doubled ones are suppressed.
Cron fails you at a specific, predictable moment: the moment one job's OUTPUT becomes another job's INPUT. That is when "run at 2:30" silently stops meaning what you needed it to mean, which was "run after the extracts succeed". Everything in this course flows from that one substitution.
Three ways to be wrong on time 7 min live
A clock-scheduled chain does not fail loudly. It publishes. Here are the three silent failures every cron-run pipeline commits, and why no one gets paged for any of them.
Live Why nobody notices for weeks 4 min ▶
Every monitoring instinct people bring to scheduled jobs checks the wrong thing: is the process running, did the script exit zero, is the machine up. On the stale-input night, every one of those checks passes. The extract failed, but the CLEAN job exited zero - it cleaned yesterday's data flawlessly. The dashboard renders. The numbers are plausible. Plausible is the operative word: revenue that is 4 percent off because one source went stale does not look broken, it looks like Tuesday.
The failure only becomes visible when someone cross-checks against a source system, which at most companies is a month-end activity. By then there are twenty mornings of decisions sitting on top of it.
Daybreak's version: the payments extract dies at 2:04, the 7am dashboard shows card revenue flat while cash is up, and a regional manager spends the morning drafting a memo about a cash-preference trend that does not exist. The pipeline never errored. It just told yesterday's truth with today's date on it.
Self-study The padding arms race, and why it always loses 3 min ▶
The folk remedy for clock scheduling is padding: extracts at 2:00, clean at 2:30 "to be safe", then 2:45 after the first incident, then 3:15 after the second. Two things go wrong. The padding is dead time on every NORMAL night, so the dashboard gets later all year for the benefit of the occasional slow one. And no amount of padding is ever enough, because volume grows and the slowest night keeps moving.
Padding is a guess about duration standing in for a fact about completion. The next session replaces the guess with the fact: run when upstream has succeeded, however long that took. Once that wire exists, the padding - and the guessing - goes away.
Meet the nightly build 5 min live
The chain you will operate for six sessions. Seven tasks, one warehouse, one 7am promise.
Live The 7am promise, stated precisely 3 min ▶
Every scheduled pipeline serves a deadline someone actually feels, and Daybreak's is 7am: store managers check the dashboard before opening. That gives every night exactly four outcomes, and naming them now pays off all course long.
- On time and right - published by 7, numbers true. The only full success.
- Late but right - published after 7, numbers true. Annoying, visible, survivable.
- Silently wrong - published by 7, numbers false, nothing flagged. The expensive one.
- Never published - no dashboard at all. Painful, but at least it is LOUD.
Most teams instinctively rank "never published" as the worst outcome. Watch tonight's build-along challenge that ranking: a missing dashboard triggers a phone call; a wrong one triggers a memo about a trend that does not exist.
Thirty nights on bare cron ★ 22 min · everyone builds
The simulator you will upgrade for the rest of the course: thirty deterministic nights of the build you just met, run exactly the way the crontab runs it.
Read the two headline numbers together. Mornings on time: 30 out of 30 - cron never misses its minute. Mornings silently wrong: 12 out of 30. Say the pair out loud, because it is the whole lesson: this pipeline is perfectly punctual and wrong forty percent of the time.
Read the calendar squares and find the pattern that is NOT there: the red days are scattered, not clustered. Silent wrongness does not look like an outage. Each red square was a normal-looking morning that a failed extract, a late source, or an overlapping slow night quietly poisoned.
Now kill a task. Pick "clean" and run tonight's trace. Watch downstream: join and aggregate run anyway at their appointed minutes, consume whatever data is lying there, and publish. The trace ends with the sentence that should bother you: the dashboard looks exactly like every other morning.
Check the history counter: 26 of 30 days correct. Four mornings this month carried a logic bug (days 10 through 13) that no scheduler in any session can prevent - code bugs are code bugs. Keep an eye on that counter; in session 5 it becomes fixable.
Why the numbers are trustworthy: which tasks blip and which nights run slow is a fixed-seed teaching script, so every run of the month is comparable. What the scheduler does about each event - run anyway, wait, skip, retry, rerun - is genuinely computed, and it is the part the levers will change.
Before session 2 15 min
- Find one clock-scheduled chain you rely on (crontab, scheduled query, "runs nightly" anything). Write down its tasks and draw the real dependency arrows between them, the way part 3 did for Daybreak.
- For that chain, name its 7am: the moment a real person consumes the output. If you cannot name one, note that too - a pipeline with no consumer deadline is its own finding.
- Classify its last bad morning using the four outcomes: late-but-right, silently wrong, never published. If you cannot tell which it was, write down WHY you cannot tell - that answer is session 6's alerting material arriving early.
Three questions
1. What does cron actually promise about a scheduled command?
The crontab man page's whole contract is time-field matching, checked every minute. Dependencies, retries and overlap protection are not weaknesses in cron's implementation - they are simply not in the contract.
2. The 2:00 extract dies. What does the 2:30 clean job do under cron?
Cron has no idea clean and the extract are related. Clean fires at 2:30, finds yesterday's partition where tonight's should be, exits zero, and the morning looks completely normal. That is the stale-input failure.
3. Thirty mornings on time, twelve silently wrong. What is the honest reading?
No amount of adjusting the minutes fixes stale inputs, overlaps or missed runs - padding is a guess about duration standing in for a fact about completion. The fix is making dependencies real, which is session 2.
Answer all three to see your score.