Data-workflow orchestration and scheduled scripts

Workflow Orchestration Versus Simple Scheduled Scripts: Evidence Dossier

Research snapshot: October 10, 2026
Perspective: General
Decision supported: When a bounded recurring business workflow should remain a scheduled script/native automation, and when durable workflow orchestration becomes the minimum sufficient solution.
Evidence base: Public documentation, primary practitioner material, current provider behavior, and explicitly labeled synthetic design/tests. No private production systems were accessed, and no customer outcome, ROI, incident reduction, or firsthand production result is claimed.

Executive decision and uncertainties

For the specific bounded workflow in scope—

source export → immutable raw preservation → ingestion → dbt/warehouse transformation → business report

—I would not adopt a workflow orchestrator merely because there are five steps. I would first implement the process as one hardened, period-aware job invoked by a reliable scheduler, with a durable state/acceptance ledger, an overlap lock, immutable input identity, idempotent or reconcilable side effects, explicit timeouts, and a reconciliation command. That is the minimum solution I would choose while the workflow remains linear, has one operational owner, runs in one execution environment, has few concurrent backfills, and can cheaply resume or rerun one business period.

A plain collection of independently scheduled cron scripts is below the reliability threshold in the stated requirements. Traditional single-machine cron is fundamentally a time-trigger mechanism: Google’s SRE description of typical crond notes that launches are fire-and-forget and not durably tracked, and that machine downtime prevents both scheduling and execution. 1 A stronger local scheduler such as systemd timers can materially improve that baseline: an already-running service is not started again by its timer, and Persistent=true can trigger after downtime when at least one calendar event was missed. But the application still has to determine which business periods are outstanding and reconcile them. 2

A managed/native scheduler is a useful middle ground, not automatically an orchestrator. Google Cloud Scheduler, for example, explicitly provides at-least-once, not exactly-once, delivery, may deliver the same scheduled invocation more than once, exposes the original schedule time for deduplication, and supports configurable retry/backoff. 3 That can eliminate a local scheduler host as a failure point while leaving workflow dependency and business-state semantics in the invoked application.

A workflow orchestrator becomes the better default when recovery complexity becomes larger than execution complexity: several independently retryable stages, frequent partial reruns and historical backfills, multiple periods concurrently in flight, long dependency waits, branching/fan-out, cross-team handoffs, or a need for standardized run history and operational UI. Airflow, for example, persists DAG/task-run concepts, models data intervals, dependencies, catchup and historical backfill. 4 Prefect likewise exposes explicit run states. These are real advantages over rebuilding the same machinery inside shell/Python code.

But an orchestrator does not make “business complete” synonymous with “workflow green.” Airflow documents that a successful leaf task with an all_done trigger rule can cause a DAG run to be marked successful even when an intermediate task failed. 4 Prefect documents that programmatic state handling can leave a failed task inside a flow whose final state is nevertheless COMPLETED. 5 The final business acceptance predicate therefore belongs in the workflow design regardless of technology.

The most important finding on time is equally technology-independent: “every 24 hours” and “every day at 06:00 local time” are different contracts. Airflow explicitly distinguishes cron schedules, which adapt to DST, from timedelta schedules whose subsequent runs maintain the UTC cadence; AWS EventBridge Scheduler similarly defines rate(1 days) as 24 elapsed hours while local cron schedules follow timezone/DST rules. 6 Cron syntax by itself does not tell you what a provider does with skipped or repeated civil times: current AWS, GitHub Actions, and Debian/Vixie cron documentation describe different transition behavior. 7

My decision boundary is therefore:

Situation	Recommended minimum
Process is still ambiguous, rare, or changing	Manual/native runbook first
One linear daily chain, one owner/runtime, low backfill volume, whole-period rerun is safe	Hardened scheduled job + durable period ledger
Same bounded job, but scheduler-host reliability is undesirable	Managed/native scheduler + hardened job
Frequent partial recovery/backfill, multiple dependencies or owners, several runs/periods in flight, operational UI/history materially valuable	Workflow orchestrator
Script contains a task graph, per-task persistent states, queues, retry policies, dependency waits, backfill planner and recovery UI	Stop pretending it is “just a script”; it has become a bespoke orchestrator

The last boundary is an editorial architecture judgment, not a measured threshold.

Confidence is high in the documented scheduler, DST, retry, Airflow-state and dbt behaviors because they come from current provider/project documentation. Confidence is moderate in the decision boundary because it is an architectural synthesis rather than a controlled comparative experiment. Confidence is low/unknown for any universal ROI, incident-rate, MTTR or cost break-even: I did not identify a controlled study running this identical workload under a hardened script and an orchestrator, and this dossier therefore claims no effect size or causal business outcome.

Bounded process and minimum baseline

The following is a synthetic reference process, not a report about an observed company.

Contract element	Proposed reference design
Business purpose	Produce the daily business report for the correct reporting period and accepted source version
Operational owner	Analytics/Data owner; infrastructure responsibility may be the same person/team in a small implementation
Trigger	Nominally 06:00 in the declared business timezone
Business period	business_date = B, calculated independently from trigger time using a versioned business calendar
Source input	Export explicitly identifying B and source_version = V, or a generated immutable version identity plus content hash
Raw preservation	Immutable copy identified by B, V, and SHA-256 hash H
Processing states	EXPECTED → RECEIVED → RAW_PRESERVED → INGESTED → TRANSFORMED → VALIDATED → PUBLISHED → ACCEPTED
Non-success states	TIMED_OUT, FAILED, SUPERSEDED; cancellation is also non-success
Main exceptions	Late/missing source, wrong period, revised source version, duplicate trigger, overlap, permission failure, partial write/load, transformation failure, stale downstream data, publication uncertainty, host/scheduler outage, DST replay/backfill
Observable end state	Durable acceptance record proving that the published artifact corresponds to the required B and V and met—or missed—the declared deadline

The proposed business success predicate is deliberately stricter than process exit status:

BusinessSuccess(B,V) =
Raw(B,V)
\land Ingested(B,V)
\land Transformed(B,V)
\land Validated(B,V)
\land Published(B,V)
\land Accepted(B,V)
\land accepted\_at \le D(B)

where:

• (B) = business/reporting date,
• (V) = accepted source version,
• (D(B)) = declared acceptance deadline for that business period.

If the data is repaired after the deadline, correctness may be restored, but the historical deadline result must not be rewritten. A practical acceptance record should therefore preserve accepted_at and deadline_met=false.

This separation is important because Airflow itself distinguishes a run’s data interval/logical date from actual execution time; a daily run is associated with a data interval and is normally scheduled after that interval ends. Its documentation also warns that manually supplied logical dates and data intervals should not simply be assumed equal. 4 The general lesson is not “copy Airflow terminology into every script”; it is to keep business period, nominal trigger time, actual start time, and source version as separate fields.

The simplest baseline is not cron. It is a manual runbook:

A person determines B, checks that the correct source version has arrived, preserves it immutably, runs ingestion, invokes the transformation, validates that the result is actually for B/V, produces the report and records acceptance. That baseline exposes the information the automated system must eventually encode. If the human cannot state whether a revised export supersedes an already-published report, or what “late” means, adding Airflow merely converts an undefined process into an undefined DAG.

Before selecting technology, I would simplify the process in three ways.

First, remove independent clocks where dependencies already exist. There is little justification for “ingestion at 06:00, dbt at 06:10, report at 06:20” when what the business means is “transform the correct export after it is ingested, then publish the result.” Fixed offsets turn data readiness into an unstated probability.

Second, standardize identity before retry policy. Every stage should know business_date, source_version and ideally the raw content hash. Google’s distributed-cron design emphasizes that identifying only the job is insufficient; an individual launch needs a unique identity so failover does not create ambiguity about which launch already happened. 1 Amazon’s Builders’ Library makes the analogous point for retryable side effects: a stable caller-supplied request identifier enables a service to recognize retries of the same intent, while merely comparing parameters can be semantically ambiguous. 8

Third, define the acceptance gate before automation. dbt can contribute useful mechanics: current dbt documentation says dbt build executes selected resources in DAG order, produces manifest/run-results artifacts, and by default can block downstream resources after upstream test failures. 9 But dbt freshness is fundamentally an age/freshness comparison—such as comparing a maximum loaded timestamp with the current time—not proof that a report uses the exact business date or source version intended by this contract. 10 The latter requires an explicit period/version test or equivalent lineage check.

There is no material Czech-versus-US change to this architecture boundary in the evidence inspected. The material contextual differences are the chosen IANA timezone and business calendar. For examples in this dossier, the Czech case uses Europe/Prague and the US Eastern case uses America/New_York. Holiday lists are treated as business-owned versioned inputs, not as something inferred from the scheduler.

Decision boundary across implementations

The central mistake is to compare “cron” with “Airflow” as products. The more useful comparison is where the required state lives and who owns recovery.

Dimension	Plain cron + independent scripts	Hardened single job + local/managed scheduler	Native automation/workflow facility	Durable orchestrator
Scheduling	Time trigger	Time trigger, provider/local implementation semantics explicit	Built-in platform schedule/event	Schedule plus workflow model
Dependency handling	Usually implicit clock offsets or custom code	Explicit sequential application code	Varies by native platform	First-class graph/state is typical
Business-period identity	Custom	Custom and required	Custom	Framework may provide logical interval/partition, but business version still custom
Retries	Custom shell/code	Explicit application policy	Often provider-supported at invocation/job level	Usually standardized per task/run
Duplicate safety	Custom	Idempotency/reconciliation required	Still required	Still required
Partial failure	Usually manual	Durable ledger + resume/reconciliation	Platform-specific	First-class task/run states make partial recovery easier
Backfill	Ad hoc manual rerun	CLI/API takes explicit B; reconciliation enumerates missing periods	Platform-specific	Commonly standardized; Airflow has catchup/backfill
State	Logs/process exit unless built	Small durable database/ledger	Provider run state plus application state	Metadata/state database or managed equivalent
Observability	OS logs/mail	Structured logs + ledger + alert on missing acceptance	Native execution UI/logs	Workflow/task history/UI is a primary benefit
Host interruption	Scheduler-dependent	systemd persistence or managed scheduler can improve launch recovery	Provider-dependent	Control plane usually designed around durable run state
Control-plane burden	Very low	Low to moderate	Provider is an additional dependency	Highest when self-hosted; managed services move rather than eliminate ownership
Testing surface	Script + environment	Script + ledger + recovery logic	Platform definitions + application	Workflow definition, task code, control-plane/deployment integration
Best fit	Failures/skips are tolerable	Bounded linear workflow with serious correctness requirements	Work naturally belongs inside that platform	Complex recovery/dependency state or many workflows
Main failure of the approach	Hidden skipped/duplicate/stale work	Bespoke state code grows into a hidden orchestrator	Provider scheduling guarantees mistaken for business completion	Platform complexity exceeds problem complexity

The weakest baseline deserves a precise qualification. Google’s SRE chapter characterizes conventional single-machine crond as having a machine-sized failure domain and fire-and-forget launches with no launch tracking. 1 Debian’s Vixie cron implementation does provide logging and special DST behavior, but this does not turn its timer into a durable multi-stage workflow engine. 11

The hardened script is substantially stronger than “five shell scripts in crontab.” I mean one entrypoint such as:

run_daily_report --business-date 2026-03-27

which acquires the lock for B, reconciles the current state, waits for exactly B/V, preserves raw input, executes/resumes only the necessary stages, validates the result and transactionally records acceptance. Triggering that with systemd OnCalendar= plus Persistent=true, or a managed scheduler, is a genuinely viable architecture for this bounded case. systemd documents that Persistent=true stores last-trigger state on disk and starts the service when the timer returns if it would have fired while inactive. 2 Because that guarantee is “at least one missed occurrence existed,” rather than “materialize every missing business period as an individual workflow instance,” the proposed reconciliation ledger remains necessary; that last conclusion is an inference from the documented timer behavior.

A managed scheduler can further strengthen the launch plane without replacing the application contract. Google Cloud Scheduler documents at-least-once invocation and explicitly tells target code to be safe under repeated execution. It exposes the original scheduled time consistently across retries, which is useful as a trigger identifier. 3 Its retry configuration can also cause a future scheduled execution to be skipped when the previous execution is still retrying, demonstrating why “the scheduler has retries” is not the same as “every business period will complete.” 12

A native platform scheduler may be sufficient when the entire workflow can be expressed as one durable platform job. But its clock cannot be assumed exact. GitHub currently states that scheduled Actions workflows can be delayed during high load and that sufficiently loaded queues can drop some scheduled jobs. 7 For a business deadline, completion should therefore be independently monitored as “expected period has not reached ACCEPTED by time X,” rather than “did the scheduling service generate an event?”

An orchestrator becomes attractive when the script starts accumulating reusable orchestration mechanisms. Airflow exposes DAG runs, task dependencies, data intervals, catchup and historical backfill; catchup can generate a run for each unprocessed interval when enabled. 4 Those are exactly the facilities a sophisticated home-grown runner eventually has to reproduce.

The trade-off is a real additional system. Airflow’s own documentation describes continuously running DAG-processing processes, synchronization with its database, filesystem considerations, database-connection pressure, CPU/memory consumption and tuning decisions. 13 That does not prove Airflow is “expensive” or less reliable; it proves that orchestration has an operational surface of its own. With a managed orchestration product, much of that control-plane work moves to the provider, but provider dependency, configuration, upgrade compatibility, workflow testing and usage cost remain decision variables.

I would therefore choose an orchestrator for this chain when one or more of these become regular rather than exceptional: partial reruns from different intermediate stages; dozens of historical periods to backfill; more than one independent upstream prerequisite; periods running concurrently; long waits that should not consume a worker; branching/parallel execution; multiple operational owners; or operators who need standardized workflow-state inspection rather than SQL/CLI access to a bespoke ledger. This is a decision heuristic, not an empirical threshold.

Conversely, I would actively avoid introducing an orchestrator when there is one owner, one linear graph, perhaps one run a day, almost no partial reruns, a whole-period replay is cheap and safe, and the team would have to acquire a new control-plane skill set solely to run this one process. In that situation, complexity added “for reliability” can simply relocate failures from a small program into scheduler, worker, metadata, deployment and version-management layers. Airflow’s own deployment documentation makes those additional operational concerns concrete. 13

AI is outside the authority path in this design. A bounded agent may classify logs, summarize an incident or suggest a recovery command. It should not infer that business period B is complete because a task “looks successful,” nor replace the deterministic acceptance predicate. No evidence inspected here establishes an AI agent as a substitute for scheduler state, source-version correlation or business completion authority.

Time and period contract

The following contract is the most reusable output from the time-specific investigation. The numerical times and timeout values are synthetic design assumptions, not observed customer requirements.

Field	Proposed contract
business_date	Explicit date B; downstream tasks never derive it from now()
Business calendar	Mon–Fri minus a versioned business-owned holiday set; source calendar may be independently versioned if different
Czech timezone example	Europe/Prague
US Eastern example	America/New_York
Schedule intent	Local calendar time: nominal kickoff 06:00 local
Elapsed intent	Use elapsed/UTC interval only when the requirement literally means “N hours since previous occurrence”
Source readiness deadline	07:00 local, synthetic
Report acceptance deadline	07:30 local, synthetic
Trigger timestamp	Store nominal scheduled timestamp separately from actual start
Source identity	(business_date, source_version, source_hash)
Correlation key	daily-report:{business_date}:{source_version}
Raw path concept	raw/source/business_date=B/source_version=V/sha256=H/...
Overlap	At most one mutating run for the same B; historical periods may run concurrently only if downstream operations are isolation-safe
Same B/V/H duplicate	Resume/no-op
Same B/V, different H	Conflict; quarantine/reconcile
Same B, new V	New immutable candidate; never silently overwrite an accepted report
Source wait	Wait for exact B/V until 07:00; absence thereafter is TIMED_OUT, not permission to use latest available data
Transient retries	Synthetic sequence 30 s, 60 s, 120 s, ideally with jitter
Permanent failures	Authentication/permission, schema incompatibility and B/V validation errors require repair before retry
Cancellation	Leaves durable incomplete state; reconciliation must see it as unfinished
Backfill	Enumerate business dates directly; do not generate periods by repeatedly adding 24 elapsed hours
Completion	Only explicit acceptance of exact B/V; scheduler/orchestrator success is insufficient
Deadline history	Repair after deadline can make output correct, but must preserve deadline_met=false
TZ database	Log/runtime-manage the timezone data version; current IANA tzdb at the snapshot was 2026e, released September 29, 2026. 14

IANA explicitly notes that its timezone database is periodically updated when political bodies change UTC offsets, timezone boundaries or daylight-saving rules. 14 That is why “we configured Europe/Prague once” is not the complete operational contract. Airflow makes the same point in implementation-specific terms: its documentation warns that the underlying timezone library must be kept current and notes that its default Pendulum timezone database can lag IANA. 6

The schedule should state whether the business wants civil/calendar time or elapsed time:

Calendar contract:
"Run for each business date at 06:00 Europe/Prague."

Elapsed contract:
"Run 24 elapsed hours after the previous invocation."

Those contracts diverge at DST. Airflow 3.3.2 documents that timezone-aware cron schedules follow daylight-saving changes, while timedelta scheduling does not readjust later runs for DST and therefore retains the UTC cadence. 6 AWS EventBridge Scheduler is even more explicit: a rate(1 days) period is 24 elapsed hours, including across 23- or 25-hour civil days. 15

The more subtle point is that provider-specific treatment of nonexistent and repeated local times differs:

Implementation inspected	Documented DST behavior	Implication
Debian Vixie cron	For a forward clock change under three hours, fixed-time jobs in the skipped interval are run soon afterward; fixed jobs in the repeated interval are not rerun. 11	Do not generalize “cron skips spring jobs”
AWS EventBridge Scheduler	A cron time that does not exist in spring is skipped; at fall-back the repeated schedule is invoked only once. 15	Different from Debian behavior
GitHub Actions timezone-aware schedule	Current docs say a spring-forward time in the skipped hour advances to the next valid time; schedules can separately be delayed or dropped under load. 7	Yet another implementation contract
Airflow timezone-aware cron	Cron schedule follows DST; elapsed timedelta cadence does not readjust after the initial date. 6	Choose schedule type based on business semantics, not syntax familiarity

This directly challenges any generic statement such as “cron runs twice at fall-back” or “02:30 simply does not run in spring.” The syntax is not the execution guarantee. Inspect the actual scheduler/version.

The synthetic test asset executed for this dossier used Python 3.13.5 and the environment’s system zoneinfo. It classified:

Europe/Prague
2026-03-29 02:30 -> nonexistent local civil time
2026-10-25 02:30 -> ambiguous/repeated local civil time

America/New_York
2026-03-08 02:30 -> nonexistent local civil time
2026-11-01 01:30 -> ambiguous/repeated local civil time

It also verified that preserving 06:00 local civil time across Prague’s spring transition produces a 23-hour UTC gap, while adding 24 elapsed hours to the pre-transition instant yields 07:00 local on the following day. Across fall-back, the corresponding civil-time gap is 25 hours and 24 elapsed hours lands at 05:00 local. These are firsthand synthetic standard-library tests, not cloud-scheduler tests and not measurements of Airflow/AWS/GitHub behavior.

This distinction is the evidence-backed core of the draft claim “Automation runs at a different time than expected. Which time should count for the business?” I would keep the idea but make it more precise:

“Does the business mean 06:00 local calendar time, or every 24 elapsed hours? They are different schedules. Name the timezone, business period, DST policy and deadline explicitly.”

Dependency, timeout, recovery and worked failures

A scheduler answers “when should I try to start something?” The bounded business process needs answers to several additional questions: which period/version is this? what has completed? what is safe to retry? what timed out? and what evidence proves the final business artifact is correct?

The following recovery table is architecture-neutral; the same predicates apply whether the implementation is a Python program or an Airflow/Prefect workflow.

Stage	Dependency / readiness predicate	Timeout or failure	Durable evidence	Recovery / reconciliation
Source wait	Source declares expected B and V; completeness criterion passes	Missing/late source; wrong B/V; synthetic 07:00 timeout	EXPECTED, observed source metadata	Ignore/quarantine wrong period; resume exact B when it arrives; after timeout alert but keep B recoverable
Raw preservation	Exact source bytes available	Partial write; duplicate trigger; version/hash conflict	Immutable (B,V,H) artifact plus RAW_PRESERVED	Finalize atomically where storage permits; same H no-op; conflict blocks
Ingestion	RAW_PRESERVED(B,V)	Network/DB transient; permission error; partial load	INGESTED(B,V) plus load audit metadata	Retry only an idempotent/reconcilable operation; otherwise clean/replace/transactionally reconcile B
dbt/warehouse transform	Exact ingested B/V	dbt failure; run accidentally reads “latest” stale data	transform artifact/run reference plus period/version evidence	Re-run exact B after repair; never infer B from current time
Validation	Transformed B/V exists	Freshness/test/business invariant failure	test/validation artifact	Repair lowest failing stage; remain non-publishable
Report publication	Validated B/V	Publish timeout after side effect; duplicate publication risk	Report metadata + stable publication/idempotency key	Query external state when possible; retry same intent key; otherwise reconcile manually first
Acceptance	Published artifact explicitly identifies expected B/V	Yesterday’s data; wrong source revision; missed deadline	ACCEPTED(B,V,H) plus accepted_at and deadline result	Reject mismatch; newer V follows explicit supersession policy
Whole process	Required B has an accepted version	Scheduler/orchestrator green while no accepted business artifact exists	Independent period acceptance ledger	Scan expected B set against ACCEPTED set and reopen/resume missing periods

Amazon’s idempotency guidance illustrates why a timeout at a side-effect boundary is particularly dangerous: after the caller loses the response, it may not know whether the operation happened; a blind retry can duplicate the side effect. Amazon describes stable client request identifiers as its preferred mechanism for distinguishing retries of the same intent, together with atomic handling of the identifier and mutation. 8 Google’s distributed-cron design similarly persists an identity and begin/end state for each scheduled launch so failover can distinguish an open launch from one that was never attempted. 1

Worked failure: source arrives after the fixed schedule. This is a synthetic example, not an observed incident.

Assume Monday March 30, 2026, schedule 06:00 Europe/Prague, expected business date B=2026-03-27, and source version V1. The export is not ready at 06:00 and becomes available at 06:12.

A brittle implementation has three independent timers:

06:00 ingestion
06:05 dbt
06:15 report

The ingestion sees no source. The dbt process can nevertheless exit successfully using whatever was previously in the warehouse—for example B=2026-03-26. The report process likewise succeeds technically. All three process-level signals can therefore look benign while the business output is stale. This sequence is a synthetic failure construction, not a measured provider result.

The hardened design instead has one period-aware chain:

trigger(06:00)
  -> expect B=2026-03-27
  -> wait for source where manifest.business_date == B
  -> observe V1 at 06:12
  -> preserve(B,V1,H)
  -> ingest(B,V1)
  -> transform(B,V1)
  -> assert output.business_date == B
  -> assert output.source_version == V1
  -> publish(B,V1)
  -> accept(B,V1)

The orchestrator variant expresses those stages as persisted task states; the hardened-script variant expresses them as state transitions in a small durable ledger. The correctness predicate is identical. The choice of technology affects how much of the state/retry/backfill machinery is supplied by the platform.

dbt helps with DAG execution and tests, but its freshness mechanism should not be substituted for that exact-period assertion: current documentation defines freshness using latest-loaded timestamp/metadata against age thresholds. 10 A “fresh enough” table can still be the wrong contractual version for a particular report; that is an inference from what freshness measures, not a dbt defect.

Worked failure: scheduler host interruption. Suppose the local host is down from 05:55 to 06:20. Typical traditional crond does not durably track the missed launch, according to Google’s SRE description. 1 A systemd calendar timer with Persistent=true can activate the service when the timer returns after a missed occurrence. 2 But the robust runner still asks:

expected_business_dates(now)
minus
accepted_business_dates()
=
periods requiring recovery

That reconciliation survives a much broader class of failures than asking whether a particular 06:00 trigger was emitted. If three business periods were missed, the ledger—not a single catch-up timer activation—determines that three periods remain outstanding.

Worked failure: duplicate trigger. Google Cloud Scheduler’s at-least-once contract means the exact same nominal schedule may produce more than one request. 3 The workflow therefore checks (B,V,H) before performing a mutating stage. A duplicate of the same identity resumes/no-ops. A new version V2 for the same B is not considered the same operation and is retained separately. If V1 was already accepted, V2 needs an explicit correction/supersession decision; it must not silently replace the prior report.

Worked failure: backfill crossing a DST transition. The executed fixture enumerated the Czech business dates:

2026-03-27
2026-03-30
2026-03-31

directly as dates, crossing the Europe/Prague DST weekend. It did not produce them by repeatedly adding 24 hours to an execution timestamp. This is the correct conceptual separation: historical B values are business periods; timezone scheduling only decides when a live trigger should occur. Airflow’s data-interval/catchup model reflects the same broad separation and specifically warns that workflows intended for catchup need to operate on the interval rather than “Now.” 4

Worked failure: publication response lost after the side effect. The worst recovery is often not a failed computation but “maybe succeeded.” Sending a report twice may be materially different from rebuilding a warehouse partition twice. The design therefore uses a stable publication key such as:

report:2026-03-27:v1

and either an external API with an idempotency contract or a query/reconciliation operation before retry. This follows the retry/idempotency architecture described by Amazon; it is not a claim that every report-delivery service implements such an API. 8

For the second draft claim—“One automation waits for another. Who ensures the whole process finished?”—I would keep the premise but sharpen the answer:

The component that owns the business acceptance state must ensure whole-process completion. A scheduler firing all steps is insufficient; an orchestrator helps only if its final gate is defined as the business completion predicate rather than merely “all runnable tasks ended.”

Airflow’s leaf-state caveat and Prefect’s programmable final-state semantics are strong counterevidence to any stronger claim that an orchestrator automatically guarantees this. 4

Firsthand synthetic execution performed for this dossier: seven assertions passed on Python 3.13.5 using system zoneinfo: Czech DST civil-vs-elapsed behavior, US Eastern transition classification, business-date enumeration across the Prague DST weekend, duplicate/hash conflict handling, stale-yesterday report rejection, durable acceptance reconciliation, and same-period/new-version supersession protection. No external provider, scheduler, dbt installation or orchestrator was executed.

The actual portable fixture is included:

Download the complete evidence assets ZIP [original file unavailable]

Open the time/period contract YAML [original file unavailable]

Open the dependency/recovery CSV [original file unavailable]

Open the executable synthetic Python fixture [original file unavailable]

The ZIP also contains acceptance_cases.json, the README and the captured test-output.json. The code uses only Python’s standard library plus the host timezone database; it deliberately does not pretend to validate AWS, Google, GitHub, Airflow, Prefect, Dagster or dbt provider behavior.

Claim-to-source evidence ledger

All sources below were inspected on 2026-10-10. “Supported” means the source directly supports the scoped formulation, not a broader universal claim.

Claim target	Primary source and exact section	Source date/version	Exact evidence scope / type	Status and editorial advice
“Traditional cron tracks whether the launched business workflow completed.”	Google SRE, Distributed Periodic Scheduling with Cron → Reliability Perspective: https://sre.google/sre-book/distributed-periodic-scheduling/ 1	Online SRE Book chapter; material was previously published in ACM Queue in 2015	Primary company engineering/practitioner design. Describes common single-machine cron and Google’s distributed-cron design, not every cron implementation.	Contradicted. Rewrite: conventional cron is primarily a launcher; completion state must come from application/orchestration/monitoring.
“Job/launch identity matters during failover and retries.”	Google SRE, same chapter, Roles of the Leader and Follower: https://sre.google/sre-book/distributed-periodic-scheduling/ 1	Same	Reported production architecture. Google records start/end state and uniquely identifies a scheduled launch by scheduled/start identity.	Supported, qualified. Keep as architecture evidence, not as proof every workflow needs Paxos.
“Cron has one universal DST behavior.”	Debian cron(8), NOTES: https://manpages.debian.org/bookworm/cron/cron.8.en.html 11	Source last updated 2023-03-02; Debian bookworm package; HTML generated later	Implementation documentation for Debian’s Vixie cron with Debian-specific fixes. Forward skipped fixed-time jobs are run soon after; repeated-time fixed jobs are not rerun.	Contradicted. Remove universal wording and always name implementation/version.
“A small local scheduler cannot catch a host-down missed calendar run.”	systemd.timer(5), Persistent=, plus activation behavior: upstream primary page was inaccessible in this research environment; Debian mirror used: https://manpages.debian.org/testing/systemd/systemd.timer.5.en.html 2	Debian testing mirror metadata observed in research; current testing systemd manpage	Upstream-manpage mirror, not directly fetched primary source. Persistent=true stores last-trigger information and activates after downtime if a run was missed; active service is not restarted by timer.	Contradicted for systemd. A hardened local baseline is stronger than classic cron. Qualify due source-access gap and note it does not create one workflow instance per missing business period.
“Managed scheduling gives exactly one invocation.”	Google Cloud Scheduler, About Cloud Scheduler → delivery / deduplication: https://docs.cloud.google.com/scheduler/docs/overview 3	Last updated 2026-10-07 UTC	Primary provider documentation. Cloud Scheduler explicitly states at-least-once delivery and possible repeated invocation.	Contradicted. Replace “once” with idempotent/reconcilable processing keyed by job + schedule/period identity.
“Scheduler retries ensure every future scheduled period still runs.”	Google Cloud Scheduler, Retry jobs → Maximum retry attempts: https://docs.cloud.google.com/scheduler/docs/configuring/retry-jobs 12	Last updated 2026-10-07 UTC	Primary provider documentation. A future scheduled execution can be skipped while retries of the previous invocation continue.	Contradicted. Reconciliation must compare expected business periods with completed/accepted periods.
“A native hosted schedule is an exact business deadline trigger.”	GitHub Docs, Events that trigger workflows → schedule: https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule 7	Page date not stated; current at inspection	Primary provider documentation. Scheduled workflows can be delayed under load and some queued jobs can be dropped.	Contradicted. Do not make “trigger observed” the only deadline monitor.
“Every 24 hours equals every day at the same local time.”	AWS EventBridge Scheduler, Daylight savings time on EventBridge Scheduler: https://docs.aws.amazon.com/scheduler/latest/UserGuide/schedule-types.html 15	Page date not stated; current at inspection	Primary provider documentation. rate(1 days) means 24 elapsed hours; timezone cron follows local-time DST rules.	Contradicted. Rewrite to distinguish elapsed interval from civil/calendar schedule.
“A nonexistent local cron time is handled the same across providers.”	AWS section above; GitHub schedule; Debian cron(8) notes. 15	Current versions as above	Cross-provider documented behavior comparison. AWS skips; current GitHub advances spring skipped time to next valid time; Debian cron runs eligible skipped fixed-time jobs soon after.	Contradicted. Strong candidate for article claim: cron expression syntax does not define provider delivery semantics.
“Timezone rules can safely be treated as static infrastructure data.”	IANA, Time Zone Database → Latest version: https://www.iana.org/time-zones 14	tzdb 2026e, released 2026-09-29	Primary standards/data-maintainer source. IANA states rules are periodically updated in response to political changes.	Contradicted. Log/update TZ data and add a freshness trigger when relevant zones/rules change.
“Airflow calendar cron and elapsed duration schedules have identical DST semantics.”	Airflow 3.3.2, Time Zones → Cron schedules / Time deltas: https://airflow.apache.org/docs/apache-airflow/stable/authoring-and-scheduling/timezone.html 6	Apache Airflow 3.3.2; page date not stated	Primary project documentation. Cron follows DST; subsequent timedelta runs do not readjust for DST. Airflow also warns about timezone-library freshness.	Contradicted. Keep the calendar-vs-elapsed distinction explicitly.
“Airflow gives durable concepts for period/catchup/backfill that a script would otherwise implement.”	Airflow 3.3.2, Dag Runs → Data Interval / Catchup / Backfill: https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/dag-run.html 4	Airflow 3.3.2	Primary project documentation. Data intervals, catchup and historical backfill behavior.	Supported. This is a real reason to adopt orchestration when historical/partial recovery becomes regular.
“A green Airflow DAG necessarily means every important task succeeded.”	Airflow 3.3.2, Dag Run Status: same URL above. 4	Airflow 3.3.2	Primary project documentation. Leaf-node and trigger-rule semantics can produce DAG success despite an intermediate failure.	Contradicted. Final business acceptance must be modeled explicitly.
“A COMPLETED Prefect flow proves that no task failed.”	Prefect v3, States → Flow return values: https://docs.prefect.io/v3/concepts/states 5	Prefect v3, page date not stated	Primary project documentation. Programmatic handling can allow an internal failed task while the flow returns successfully and is completed.	Contradicted. Same editorial treatment as Airflow: workflow final state is only as meaningful as its definition.
“dbt can execute transformation/tests in dependency order and leave execution artifacts.”	dbt Developer Hub, dbt build → Details: https://docs.getdbt.com/reference/commands/build 9	Current docs updated 2026-09-16; v2 behavior noted on page	Primary project documentation. Build DAG ordering, manifest/run results and default skip behavior after upstream test failures.	Supported. Use artifacts/tests as evidence, but still pass and validate contractual B/V.
“dbt freshness alone proves this is the exact reporting period/source version.”	dbt Developer Hub, dbt freshness → How freshness is evaluated: https://docs.getdbt.com/reference/commands/freshness 10	Current docs updated 2026-09-16; v2	Primary project documentation. Freshness compares latest timestamp/metadata against age thresholds.	Contradicted as a completeness claim. Add explicit period/version tests; freshness is adjacent evidence.
“Retries can be blindly repeated after an uncertain response.”	AWS Builders’ Library, Making retries safe with idempotent APIs → Retrying and side effects / Reducing client complexity: https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/ 8	Rendered page did not expose a reliable publication date; inspected 2026-10-10	Primary company engineering guidance with concrete AWS practice. Discusses uncertainty after timeout, duplicate side effects, client request IDs and atomic idempotency records.	Contradicted. Retry only with idempotency/reconciliation semantics appropriate to the side effect.
“An orchestrator has zero operational surface of its own.”	Airflow 3.3.2, Dag File Processing / fine-tuning: https://airflow.apache.org/docs/apache-airflow/stable/administration-and-deployment/dagfile-processing.html 13	Airflow 3.3.2	Primary project documentation. Continuous DAG parsing, DB/filesystem, CPU/memory and tuning considerations.	Contradicted. Do not say “orchestrator is always more reliable/cheaper.” Treat control-plane ownership as part of the decision.

The source pattern is important: the strongest evidence here establishes specific system semantics, not a universal ranking. Provider docs can tell us whether a scheduler is at-least-once or how it handles DST; they cannot tell us that “Airflow saves 37% of operational effort” for this synthetic company. No such outcome is claimed.

Contradictions, gaps, assets and freshness triggers

The central recommendation survives several serious challenges.

Counterargument: “systemd or a managed scheduler is already reliable enough, so an orchestrator is unnecessary.” For the bounded linear chain, this is often correct. systemd can catch missed local calendar activation and suppress another timer activation while its service is active; Google Cloud Scheduler externalizes the trigger and provides retry/deduplication information. 2 If one program can cheaply reconcile the whole period, an orchestrator may add little. This is why the recommendation is not “use Airflow for five steps.”

Counterargument: “A script can implement everything an orchestrator does.” In principle, yes. A script plus SQL can represent task states, leases, retries, timeouts, backfills and historical run metadata. The issue is not capability but whether bespoke orchestration remains the cheapest thing to own. Once the application contains a dependency scheduler, retry queue, per-task run database, historical backfill planner and operational inspection layer, the argument for a standard orchestration abstraction becomes much stronger. That boundary is interpretive rather than experimentally measured.

Counterargument: “Orchestration itself means reliability.” The evidence does not support this as a general statement. Airflow can reach a successful DAG state despite an intermediate failure under documented trigger-rule conditions, and Prefect can complete a flow after a failed task has been programmatically handled without propagating failure. 4 A poorly modeled orchestrator can therefore be more confidently wrong than a small script.

Counterargument: “Just monitor source freshness.” Freshness is useful but weaker than period/version completion. dbt’s current freshness mechanism measures age using timestamps or adapter metadata. 10 The requested business requirement is categorical: is this exact accepted report built from B and V? Those are different predicates.

Counterargument: “DST is an edge case we can ignore.” DST is not the main reason to buy an orchestrator, but it is a reason to specify time correctly. More importantly, the evidence shows that even schedulers using cron-like expressions do not agree on skipped-hour behavior. 11 The practical fix is cheap: avoid transition-hour schedules when possible, use an IANA timezone, keep business period separate from trigger timestamp, and reconcile missing periods independently of clock events.

Unresolved evidence gap: I found no controlled empirical comparison measuring the same bounded reporting workflow under (a) a hardened script and (b) a workflow orchestrator while holding failure requirements constant. There is therefore no evidence-backed universal threshold such as “after N tasks Airflow reduces incidents,” no justified MTTR effect size, and no universal cost or ROI claim. The recommendation instead combines documented component behavior with explicitly labeled architecture reasoning.

Operational-cost gap: exact economics depend on deployment model, cloud/provider, worker/runtime demand, existing team capability and whether an orchestrator is already an organizational standard. A team already operating Airflow has a very different marginal cost from a five-person company adopting and operating it only for one daily report. No generic dollar estimate is defensible from the inspected evidence.

Market/context gap: no inspected evidence established a material Czech-versus-US difference in the architectural choice itself. The concrete differences relevant to this dossier are timezone rules and business-calendar inputs. Security, residency, labor, sector regulation or contractual retention rules could alter control-plane choices in a real deployment, but those are outside the bounded evidence collected here and should not be inferred.

Source-access gaps: the direct freedesktop.org systemd manpage returned HTTP 403 in the research environment, so the corresponding behavior was checked against Debian’s current testing mirror of the systemd manpage and explicitly labeled as such. The attempted man7 cron pages timed out; Debian’s package-specific Vixie cron manpages were used instead, and all DST claims were restricted to that implementation rather than generalized to “cron.” No PDF evidence was required for the conclusions above.

Candidate article angles emerge as distinct pieces rather than one generic “cron versus Airflow” article:

Angle	Defensible thesis	Most useful evidence/caveat
A green job is not a finished business process	Define completion in business-period/version terms, not task/process exit status	Airflow and Prefect final-state counterexamples; synthetic stale-yesterday scenario. 4
Cron is not the real enemy; hidden state is	A hardened scheduled program can be the minimum sufficient architecture for a bounded linear workflow	Traditional cron limitation versus systemd/managed scheduler improvements. 1
Every 24 hours is not every day at 06:00	Civil/calendar scheduling and elapsed intervals diverge, and cron-like providers differ at DST	Airflow, AWS, GitHub and Debian behavior. 6
When a script quietly becomes a workflow engine	The adoption boundary is recovery/state complexity, not merely number of steps	Airflow data intervals/catchup/backfill plus its own operational surface. 4
One automation waits for another—who owns “done”?	Dependency execution and whole-business-task acceptance are different responsibilities	Google launch identity, Airflow/Prefect final-state semantics, acceptance ledger. 1

Useful assets already produced: the YAML time/period contract can serve as a design-review template; the CSV dependency/recovery table can become a runbook worksheet; the JSON acceptance cases can seed tests; and the Python fixture demonstrates the distinction between civil and elapsed time plus minimal durable acceptance semantics. These assets are synthetic and portable text/code rather than screenshots of a particular vendor.

Freshness triggers for this dossier:

Trigger	What should be rechecked
IANA publishes a timezone change affecting Europe/Prague, America/New_York or another deployed zone	DST/offset fixtures and runtime timezone-library version. IANA’s database is intentionally updated as rules change. 14
Airflow major/minor upgrade	DAG-run leaf semantics, catchup/backfill, timezone behavior and deployment architecture
Prefect major version/state-model change	Final-state propagation, retries, workers and timeout semantics
Google Cloud Scheduler guarantee/retry update	At-least-once delivery, deduplication identifiers and overlapping retry behavior
AWS EventBridge Scheduler scheduling change	Rate-versus-calendar interpretation and DST skipped/repeated behavior
GitHub Actions schedule behavior changes	DST behavior, delay/drop caveats, minimum cadence and timezone support
dbt major version	Build/test propagation, artifacts, freshness behavior and suitable exact-period/version assertions
Process gains another independent source or owner	Re-evaluate orchestrator boundary immediately
Frequent partial backfills or multiple concurrent periods appear	Re-evaluate whether the bespoke ledger is becoming a hidden orchestrator
Publication acquires a non-idempotent external side effect	Strengthen reconciliation/idempotency contract before increasing retries
Business deadline/calendar changes	Update the period contract independently from scheduler syntax

The most reusable conclusion is consequently narrower than “orchestrators are better”:

Use the smallest system that can durably answer four questions: which business period/version is this, what has definitely happened, what is safe to retry, and has the business outcome actually been accepted?

For the bounded daily chain studied here, that can still be a hardened scheduled program. Once answering those questions requires a growing task-state machine, frequent partial/backfill operations, several dependencies or multiple operational owners, a durable orchestrator stops being infrastructure fashion and starts replacing machinery you would otherwise have to build and maintain yourself.

Portable citation index

[1] Google SRE: Distributed Periodic Scheduling with Cron Service

[2] systemd.timer(5) — systemd — Debian testing — Debian Manpages

[3] About Cloud Scheduler  |  Google Cloud Documentation

[4] Dag Runs — Airflow 3.3.2 Documentation

[5] States - Prefect

[6] Time Zones — Airflow 3.3.2 Documentation

[7] Events that trigger workflows - GitHub Docs

[8] references-details-empty

[9] About dbt build command | dbt Developer Hub

[10] About dbt freshness command | dbt Developer Hub

[11] cron(8) — cron — Debian bookworm — Debian Manpages

[12] Retry jobs  |  Cloud Scheduler  |  Google Cloud Documentation

[13] Dag File Processing — Airflow 3.3.2 Documentation

[14] Time Zones

[15] Schedule types in EventBridge Scheduler - EventBridge Scheduler

Workflow Orchestration versus Simple Scheduled Scripts: Evidence Dossier

Research snapshot: 2026-10-10
Perspective: Academic / systems-design evidence
Decision supported: How to choose between a scheduled script, native scheduler/automation, and a workflow orchestrator for the same bounded task and failure requirements
Scope: Public original sources plus an explicitly synthetic daily reporting process and locally executed synthetic tests. No private production systems, provider accounts, customer results, or prior project reports were used.

Decision answer and uncertainty

For the bounded daily chain studied here—source export → immutable raw preservation → ingestion → dbt/warehouse transformation → business report—the best default is not “use an orchestrator” and not “just put five jobs in cron.” It is:

First define one business-completion contract. Then use the simplest mechanism that can preserve that contract under failure.

For a small, serial, single-owner workflow, that can legitimately be one scheduled program plus a durable per-period ledger, lock/idempotency keys, explicit version checks, bounded waits, reconciliation, and alerts. A full workflow orchestrator becomes preferable when per-step retries, historical backfills, multiple concurrent periods, branching dependencies, long waits, cross-team handover, or operator visibility become routine enough that the script is accumulating its own orchestration control plane.

This conclusion is an architectural interpretation, not an empirical finding that one technology has a universal lower incident rate or lower total cost. I found strong documentation for scheduler and orchestrator semantics, and strong older systems research supporting explicit dependency and end-to-end correctness models, but no controlled study that establishes a general reliability or ROI threshold for a small warehouse team choosing cron/script versus Airflow-like orchestration. The closest workflow research focuses on modeling expressiveness or scientific/distributed workloads rather than this small-team operational decision. 1

The central distinction is:

\text{Trigger success} \neq \text{task success} \neq \text{business completion}

Schedulers principally decide when an attempt should be made. Workflow engines additionally model dependencies and execution state. Neither automatically knows whether the report represents the correct business period and source version. That last property belongs in the application/workflow contract. This follows the classic end-to-end design principle: a lower layer can help, but correctness that requires application knowledge must ultimately be checked where that knowledge exists. 2

Practical decision summary

Approach	Verdict for this bounded chain	Main reason
Manual checklist	Valid initial baseline	Makes the actual business contract visible before automation; poor scalability and handover
Several independent scheduled jobs	Reject for the stated failure requirements	Uses clock order as a proxy for dependency/version correctness
One scheduled script, no durable state	Acceptable only for low-consequence best-effort work	Easy to operate, but weak recovery/reconciliation semantics
One scheduled script + durable ledger/lock/checks	Best simplicity baseline	Can meet the bounded requirements without a separate orchestration control plane
Managed scheduler + the same robust script	Strong intermediate option	Adds provider retry/time-zone/DLQ facilities while leaving business-state logic in the worker
Workflow orchestrator	Prefer as complexity grows	Standardizes task dependencies, state, selective retry, backfill and operator visibility
Durable managed workflow service	Alternative when long waits/external service coordination dominate	Can persist/checkpoint control-flow state without self-hosting Airflow-like infrastructure

Representative schedulers themselves document that duplicate or missed invocations can occur: Kubernetes says a CronJob may under some circumstances create two Jobs or none and therefore recommends idempotent Jobs; Google Cloud Scheduler says rare duplicate requests are possible and recommends idempotent handlers. 3 Airflow, meanwhile, has a persistent scheduler and metadata database and can model data intervals, dependencies, catchup and backfill—but those capabilities introduce their own operational system and upgrade lifecycle. 4

Confidence by claim type: high for documented behavior of the inspected versions/services; high for the need to distinguish business period from trigger time; medium for the recommended escalation threshold from script to orchestrator; low for any universal cost, incident-rate or ROI comparison because the required comparative empirical evidence does not appear to exist in the inspected literature.

Bounded process and the alternatives being compared

The recognizable process

The dossier uses one synthetic but realistic reporting workflow. Nothing in this process is claimed as a customer deployment or firsthand production experience.

Element	Synthetic process contract
Business purpose	Deliver the correct daily management report
Process owner	Data/Analytics on-call owner
Trigger	06:30 local civil time on eligible business days
Business time zone	Europe/Prague
Reporting period	Previous eligible business date, determined independently of trigger timestamp
Primary input	Source export plus manifest containing business_date, immutable source_version, checksum/control metadata
Processing	Preserve raw → ingest → transform/dbt → render report
Identity propagated downstream	(business_date, source_version)
Soft source timeout	07:30 local
Business deadline	08:30 local
Success	The durably published report passes checks and declares the same business_date and source_version as the accepted source manifest
Key exceptions	Late source, duplicate trigger, overlap, partial failure, stale downstream state, permission/configuration failure, scheduler/host outage, DST transition, backfill
Recovery unit	The exact (business_date, source_version) rather than “whatever is latest now”

The times are synthetic design inputs, not industry recommendations.

The most important process-design move happens before selecting technology: eliminate implicit synchronization by clock time. Instead of saying “ingest at 06:45 because export should be done by then, run dbt at 07:00 because ingest should be done,” every stage consumes an explicitly identified predecessor. That is consistent with workflow research that deliberately separates workflow requirements and patterns from particular workflow languages and products. 1

Lamport’s classic distributed-systems treatment is also relevant, with an important qualification: it is not a study of batch schedulers. Its formal point is that causal order and physical-clock order are different concepts. Applying that principle here is an inference: “task B happened later on a clock than task A” is not proof that B consumed A’s intended result. An explicit dependency/version identity is stronger evidence. 5

Simplest manual/native baseline

Before automation, an operator can execute the same contract manually:

The owner checks for manifest(B,v), verifies that it is the expected period, preserves the raw export without overwriting another version, launches ingestion, launches the transformation after verifying the ingested (B,v), renders the report, and accepts it only after verifying its period/version and control totals.

That manual baseline is operationally expensive, but it is conceptually useful: automation should preserve those decisions, not merely automate the button presses.

A second simplification is even more important: if the chain is strictly serial, one process that executes all four technical stages sequentially is safer and simpler than four independent cron expressions. Sequential process execution supplies basic control-flow ordering mechanically. Durable state is still needed because a process can die between stages, and explicit version checks are still needed because a successful command can consume stale external data.

Same requirements, different implementations

Requirement	Independent schedules	One script + durable state	Managed native scheduler + script	Airflow-like orchestrator
Trigger at configured time	Yes	Yes	Yes, provider-specific semantics	Yes
Exact dependency correlation (B,v)	Must be custom	Custom, straightforward	Custom	Workflow can carry it, but application must define it
Sequential dependency	Clock convention unless custom checks added	Direct control flow	Direct control flow in target worker	Native DAG dependency model; scheduler launches ready tasks after dependencies complete 4
Retry	Per-script/custom	Custom bounded retry	Often provider retry + application retry	Task retry is modeled by orchestrator
Duplicate protection	Custom	Custom lock/idempotency key	Still required; scheduler duplicates can occur 6	Still required for externally visible side effects
Partial-failure resume	Awkward	Ledger identifies committed step	Same as script	Task state supports selective rerun/backfill; application-side idempotency still matters 7
Backfill by historical period	Custom CLI/loop	Simple if period is first-class	Same	Explicit catchup/backfill facilities 7
Durable execution history	Logs/custom table	Small custom ledger	Worker ledger + provider invocation logs	Metadata/control plane
Whole-workflow status	No	Custom acceptance state	Custom acceptance state	Native DAG status, but DAG status still needs careful design 7
Operator visibility	Fragmented	Small dashboard/query/alerts needed	Provider + application state	Usually materially better standardized visibility
Infrastructure/upkeep	Low	Low-to-moderate	Moderate vendor dependency	Higher when self-managed: scheduler, metadata DB, deployments and migrations 4
Best fit	Best-effort independent jobs	Bounded serial workflow	Bounded workflow wanting managed triggering	Growing dependency/backfill/operator complexity

A significant counterexample to “orchestration necessarily means a heavy self-hosted control plane” is a managed workflow service. Google Workflows says it checkpoints state after each step, replicates across zones, supports retries/timeouts/error handling, waits, and integrated logging/monitoring. That is provider-documented architecture, not independently measured reliability, but it demonstrates that the control-plane trade-off depends heavily on deployment model. 8

Why a scheduler is not a dependency manager

Provider documentation is unusually helpful here because different real schedulers visibly make different choices.

Google Cloud Scheduler may send duplicate requests; it exposes the original scheduled time in a header for deduplication, skips later scheduled runs while an earlier run is still in progress, and can retry failures with configurable exponential backoff. 6 Kubernetes CronJob provides startingDeadlineSeconds and same-CronJob concurrency policies, yet still documents approximate Job creation and possible duplicate or absent Jobs. 3 AWS EventBridge Scheduler offers retries/DLQ integration and calendar/rate scheduling semantics. 9

These are useful trigger-level facilities. None of those facilities, by themselves, can know that a warehouse table reflects source export version v for business date B. That information has to be carried and checked by the target application or by a workflow whose tasks explicitly model it.

Why an orchestrator is not automatically “correct”

Airflow’s own documentation gives a particularly useful counterexample to simplistic “green DAG = correct workflow” reasoning. DAG-run state is determined from leaf tasks, and Airflow warns that a leaf task with an all_done trigger rule can succeed and cause the whole DAG run to be reported as successful even though something failed earlier. 7

Airflow’s data-interval model is valuable: a run has an explicit interval, logical date denotes the interval rather than execution time, catchup can create runs for missing intervals, and backfill can re-run historical intervals. 7 But the engine cannot infer whether an external export stamped 2026-10-09 is the correct source version just because a task returned exit status zero. The end-to-end acceptance condition remains necessary. 2

That is the strongest argument against framing the decision as “cron versus reliability.” The actual choice is closer to:

Where should durable state, dependency semantics, recovery logic and operator visibility live?

Evidence synthesis around time, dependency and recovery

Time is part of the business contract

There are at least four time concepts in this workflow, and collapsing them is a common design error:

1. Business period — e.g. reporting date B.
2. Local civil/calendar schedule — e.g. “06:30 Europe/Prague on a business day.”
3. UTC instant — unambiguous timestamp for logging/events.
4. Elapsed duration — e.g. “retry after 15 minutes.”

These are not interchangeable.

AWS explicitly distinguishes cron/calendar scheduling from rate scheduling. Its documentation says a rate(1 days) schedule represents a 24-hour duration, so DST does not redefine the duration; its local cron schedules, in contrast, are evaluated in the specified IANA time zone. On spring-forward, a nonexistent scheduled local time is skipped; on fall-back, EventBridge Scheduler says the repeated scheduled local time runs once rather than twice. 9

Google Cloud Scheduler similarly describes its cron execution as wall-clock based, supports explicit time zones, defaults to UTC, and warns that DST can make local-time executions behave unexpectedly around repeated times; it recommends UTC when a precise cadence rather than local civil time is required. The inspected page was last updated 2026-10-07. 10

Those two providers do not establish a universal cron rule. They establish the opposite: the semantics belong to the implementation contract and must be inspected. Kubernetes has yet another explicit model: a CronJob can specify .spec.timeZone; if omitted, the schedule is interpreted relative to the kube-controller-manager local zone. 3

Airflow stores datetime data internally in UTC while supporting IANA-zone-dependent schedules, and its documentation specifically flags DST as a source of local-time errors. It also warns that Pendulum’s bundled timezone database may be less current than the IANA database unless configured to use system timezone data. 11

Inline time/period contract

For the synthetic case, the contract is:

B = \operatorname{PreviousEligibleBusinessDate}
  (\operatorname{LocalDate}(\text{trigger instant}, \text{Europe/Prague}), C)

where (C) is the organization’s explicit business calendar.

The workflow identity is:

R=(\text{workflow\_id}, B, v)

where (v) is the immutable accepted source version.

Business completion is:

\begin{aligned}
Accepted(B,v) = {} &
ManifestValid(B,v) \\
&\land RawChecksum(B,v)=ManifestChecksum(B,v) \\
&\land Ingested(B,v) \\
&\land Transformed(B,v) \\
&\land ReportPublished(B,v) \\
&\land ControlChecksPass(B,v)
\end{aligned}

and timeliness is a separate property:

OnTime(B,v)=Accepted(B,v)\land accepted\_at\le D(B)

A report can therefore be correct but late, or on time but incorrect. Those should not collapse into one boolean.

Time/period field	Contract	Rationale
Business time zone	Europe/Prague	Explicit organizational choice, not host default
Calendar trigger	06:30 local on eligible business days	“Same local business time” requirement
Business date	Previous eligible business date	Independent of run timestamp
Weekend/holiday policy	Explicit supplied business calendar	Weekday cron is not a business-calendar definition
Storage/log timestamps	UTC instants	Unambiguous event timestamps; Airflow similarly stores datetimes in UTC 11
Retry delays	Elapsed durations, e.g. 5m/15m/30m	Retry duration must not redefine reporting period
Dependency ID	(business_date, source_version)	Correlates the right upstream result rather than “latest”
Soft source timeout	07:30 local	Synthetic owner decision
Business deadline	08:30 local	Synthetic owner decision
DST nonexistent time	Never silently invent an instant; apply documented scheduler policy or reject configuration	AWS explicitly skips nonexistent cron occurrence; other providers may differ 9
DST repeated time	Declare first/second/once policy rather than assume	AWS chooses once; Google warns of wall-clock anomalies 9
Backfill	Enumerate B values	Avoid making a 23/25-hour civil day equivalent to 24 elapsed hours
Completion	Acceptance of exact (B,v)	The final business state, not merely process exit status

For a US deployment the architecture does not materially change: replace Europe/Prague with the intended IANA business zone, such as America/New_York, and provide the organization’s US business calendar. AWS’s own documentation uses America/New_York as a scheduling example. 9 There is no useful Czech-versus-US technology recommendation here; the meaningful local differences are the calendar, zone rules and business deadlines.

Dependency state, timeout and recovery contract

State	May enter when	May advance when	Timeout/deadline	Recovery	Whole task complete?
waiting_source	Period (B) created	Exact manifest(B,v) passes validation	07:30 synthetic soft cutoff	Mark blocked_source_late; alert/poll; resume same (B) when exact source arrives	No
raw_preserved	Manifest accepted	Immutable raw checksum matches manifest	Example 10 min step timeout	Idempotent retry; never overwrite another version	No
ingested	Raw (B,v) verified	Warehouse landing state records (B,v) and control totals	Example 20 min	Retry/repair exact (B,v); reconcile duplicates	No
transformed	Ingestion accepted	Transformation/tests correspond to (B,v)	Example 30 min	Retry failed transformation only; do not fall through to “latest” input	No
report_rendered	Transform accepted	Report metadata/checks identify (B,v)	08:15 synthetic recovery target	Re-render same (B,v); version/atomically publish	No
accepted	End-to-end checks pass	Terminal	08:30 business deadline	If later, retain correctness but mark late	Yes
failed_retryable	Transient failure	Retry budget remains and prerequisites still valid	Elapsed-duration retry budget	Same idempotency key, then escalate	No
failed_terminal	Invalid data/config/permission or exhausted budget	Human/system repair explicitly clears condition	Owner-defined	Repair cause; resume exact (B,v); record intervention	No

A scheduler retry policy alone does not implement this table. Google Cloud Scheduler, for example, retries lack of acknowledgement according to its configured backoff and notes that retries may overlap enough to cause a later scheduled execution to be skipped. 12 AWS’s DLQ contains failed invocation information after retries are exhausted, which is useful evidence for recovery, but the workflow still has to reconcile that failed invocation with the intended business period. 13

Worked failure scenario: every process is green, the report is wrong

This is a synthetic scenario, not a reported incident.

Assume report period (B) is due today.

A fragile design has four independent schedules:

Time	Scheduled event	Naïve outcome
06:30	source/export process expected	Source is unexpectedly late
06:45	ingestion	Finds no new export; implementation exits successfully/no-ops
07:00	dbt transformation	Successfully transforms the last available warehouse input
07:15	report	Successfully renders a report from that transformed data
08:30	business deadline	All technical jobs appear green, but report contains the previous version/period

Clock order gave no proof of data dependency. This is precisely the kind of distinction for which explicit causal/state relationships are stronger than time ordering, although applying Lamport’s formal distributed-system argument to this concrete warehouse case is an architectural inference rather than a result tested by his paper. 5

Under the proposed contract, ingestion cannot advance until it sees manifest(B,v). When the source arrives at 07:05, the same run resumes with that exact identity. Raw preservation records its checksum, ingestion records (B,v), transformation may only consume that accepted landing state, and reporting may only be accepted with the same (B,v). If the source remains absent at 07:30, the state is blocked_source_late, not success; the system must not silently publish an older report.

This can be implemented by either technology:

Scheduled script: the program executes the stages serially and persists a small ledger keyed by (workflow_id, B) plus step-level idempotency keys (workflow_id,B,v,step). On restart, it reads the ledger and resumes.

Orchestrator: each state becomes a task/dependency/run property, with retries and historical period execution delegated to the orchestration engine. Airflow’s scheduler natively waits for dependencies, while catchup/backfill can create historical interval runs. 4

The correctness rule is identical in both implementations. The difference is whether you implement the control plane yourself.

Host interruption and reconciliation

It is unsafe to assume that “the scheduler will catch up.” Provider behavior differs.

Google Cloud Scheduler documents one specific condition: after its API has been disabled and later re-enabled, jobs missed in the interval run immediately rather than waiting for the next normal schedule. 10 Kubernetes instead applies startingDeadlineSeconds, counts missed schedules, and documents cases where sufficiently many missed schedules prevent a catch-up Job from being created. 3 Airflow’s catchup behavior is explicitly configurable and is off by default in the documented Airflow 3.3.2 configuration example; with catchup enabled, separate runs are created for missing intervals. 7

Therefore the business workflow should have a scheduler-independent reconciliation query:

Missing =
\{B \mid B \text{ is due and eligible}\}
-
\{B \mid Accepted(B,v)\text{ exists}\}

A missing period produces a replay/backfill of the period key, not an attempt to reconstruct what a scheduler “probably would have done.”

DST crossing and actual synthetic execution

A portable synthetic asset was created and executed for this dossier:

Download the workflow reliability asset [original file unavailable]

It contains:

time_period_contract.yaml, dependency_state_table.csv, acceptance_cases.csv, synthetic_workflow.py, test_synthetic_workflow.py, and the captured observed_test_run.txt.

Actually executed: 12 Python 3.13.5 unit tests; all passed. The tests covered exact-version acceptance, a late source, rejection of a stale report, duplicate trigger deduplication, partial-failure resume, host-interruption reconciliation, Prague spring-forward nonexistent local time, Prague fall-back ambiguous local time, local-calendar versus 24-hour elapsed scheduling across DST, a DST-crossing period backfill, and a supplied business-calendar holiday/weekend case.

Not executed: Airflow, Kubernetes, EventBridge Scheduler, Google Cloud Scheduler, Google Workflows, dbt, a warehouse, cloud APIs, or any production system. The timezone tests exercised Python’s installed zoneinfo data; they must not be read as a test of any provider’s scheduling implementation.

The synthetic tests show the specific model is internally capable of keeping business_date independent from elapsed time and of rejecting stale period/version combinations. They do not demonstrate production reliability, performance, availability or cost.

Claim-to-primary-source evidence table

The table below intentionally mixes evidence classes only when they are labeled. Provider documentation establishes a provider’s stated contract, not independent empirical performance. Academic papers establish narrower principles/results and should not be inflated into product-comparison evidence.

Claim target / source	Direct URL / DOI and exact inspected scope	Source date; inspected	Evidence type	Assessment	Editorial advice
Workflow requirements can be described independently of implementation language/product	https://doi.org/10.1023/A:1022883727209 — Workflow Patterns, abstract and bibliographic metadata; full Springer article behind subscription preview	July 2003; 2026-10-10	Peer-reviewed workflow-modeling research	Supported, within modeling scope; not a reliability comparison	Keep, qualify as process-modeling evidence 1
Clock order should not be conflated with causal dependency	https://www.microsoft.com/en-us/research/publication/time-clocks-ordering-events-distributed-system/ — author publication page, discussion of partial/causal ordering and logical clocks	July 1978; 2026-10-10	Foundational formal distributed-systems work	Supported formally; warehouse application is inference	Keep with explicit inference label 5
Final correctness requiring application knowledge must be checked end-to-end	https://doi.org/10.1145/357401.357402; inspected MIT author-hosted PDF, pp. 1–2	Nov. 1984 revised article; 2026-10-10	Peer-reviewed systems design principle	Supported as design principle, not batch-specific experiment	Keep and qualify 2
Workflow abstraction can separate logical workflow from execution resources	https://doi.org/10.1155/2005/128026 — Pegasus abstract; reports workflow mapping and performance restructuring using an astronomy application	2005; 2026-10-10	Peer-reviewed system paper + application study	Supported in scientific-workflow context; not evidence of small-team operational reliability	Keep only as historical/contextual evidence 14
Airflow scheduler launches tasks when dependencies are complete and is a persistent service	https://airflow.apache.org/docs/apache-airflow/stable/administration-and-deployment/scheduler.html — “Scheduler,” including HA scheduler/metadata DB	Airflow 3.3.2, page date unstated; 2026-10-10	Project/provider documentation	Supported for Airflow 3.3.2	Keep; do not generalize to all orchestrators 4
Airflow explicitly models data intervals; logical date is not run time	https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/dag-run.html — “Data Interval,” “Manual Triggering and Data Intervals”	Airflow 3.3.2; 2026-10-10	Project documentation	Supported	Keep 7
Airflow supplies catchup/backfill but it must operate on properly period-bounded workflow logic	Same URL — “Catchup” and “Backfill”	Airflow 3.3.2; 2026-10-10	Project documentation	Supported	Keep; qualify that product feature does not guarantee app correctness 7
A successful Airflow DAG state can be misleading if leaf trigger rules are designed incorrectly	Same URL — “Dag Run Status,” all_done leaf warning	Airflow 3.3.2; 2026-10-10	Project documentation	Supported	Keep; strong counterevidence to “orchestrator = correctness” 7
Airflow time-zone handling distinguishes UTC storage from zone-dependent schedules and exposes DST concerns	https://airflow.apache.org/docs/apache-airflow/stable/authoring-and-scheduling/timezone.html — “Time Zones”	Airflow 3.3.2; 2026-10-10	Project documentation	Supported	Keep 11
Cron/calendar intervals and duration intervals are distinct concepts	https://airflow.apache.org/docs/apache-airflow/stable/authoring-and-scheduling/timetable.html — DeltaDataIntervalTimetable vs CronDataIntervalTimetable; plus AWS schedule types below	Airflow 3.3.2; 2026-10-10	Project/provider documentation	Supported in inspected implementations	Keep; do not call it universal cron syntax behavior 15
EventBridge local cron uses IANA zones; spring nonexistent occurrence is skipped, fall repeat fires once; rate(1 days) means 24 hours	https://docs.aws.amazon.com/scheduler/latest/UserGuide/schedule-types.html — “Time zones,” “Daylight savings time,” rate schedules	Living documentation, page date unstated; 2026-10-10	Provider contract/documentation	Supported for EventBridge Scheduler	Keep provider name in claim 9
EventBridge can send failed invocations to a DLQ after retries	https://docs.aws.amazon.com/scheduler/latest/UserGuide/configuring-schedule-dlq.html — DLQ behavior	Living documentation, page date unstated; 2026-10-10	Provider documentation	Supported	Keep as trigger-level recovery evidence, not business reconciliation 13
Google Cloud Scheduler is wall-clock based, supports zones, and warns about DST anomalies	https://docs.cloud.google.com/scheduler/docs/configuring/cron-job-schedules — “Time zone”	Last updated 2026-10-07; 2026-10-10	Provider documentation	Supported for Cloud Scheduler	Keep and qualify provider scope 10
Duplicate scheduled invocations remain possible and handlers should be idempotent	https://docs.cloud.google.com/scheduler/docs/creating — duplicate-instance/idempotency note and schedule-time header	Last updated 2026-10-07; 2026-10-10	Provider documentation	Supported	Keep 6
Cloud Scheduler retry semantics can interact with subsequent scheduled executions	https://docs.cloud.google.com/scheduler/docs/configuring/retry-jobs — maximum attempts/duration/backoff	Current inspected page; 2026-10-10	Provider documentation	Supported	Keep 12
Kubernetes CronJobs have deadlines/concurrency controls but Job creation remains approximate	https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/ — “Deadline,” “Concurrency policy,” “Job creation”	Last modified 2026-05-13; 2026-10-10	Open-source project documentation	Supported for inspected Kubernetes docs	Keep; strong reason for idempotency 3
Kubernetes CronJob time zone is explicit; absent it uses controller local zone	Same Kubernetes URL — “Time zones”	Last modified 2026-05-13; 2026-10-10	Project documentation	Supported	Keep 3
An orchestrator has its own upkeep and failure surface	https://airflow.apache.org/docs/apache-airflow/stable/installation/upgrading.html — DB migrations, backups and migration failure recovery	Airflow 3.3.2; 2026-10-10	Project operational documentation	Supported for self-managed Airflow	Keep; do not generalize maintenance burden to fully managed services 16
Managed workflow engines can checkpoint execution state and survive infrastructure outages without self-hosted Airflow	https://cloud.google.com/workflows — “All features,” checkpointing, retries/timeouts, logging	Living provider page; 2026-10-10	Provider architecture claim	Supported as documented design; operational result unverified independently	Keep as counterexample, qualify strongly 8
dbt can explicitly evaluate source freshness rather than assuming a scheduled source is current	https://docs.getdbt.com/reference/commands/freshness — freshness command/artifact behavior	Last updated 2026-09-16; 2026-10-10	Provider/project documentation	Supported, but freshness alone is not the (B,v) acceptance contract	Optional supporting context only 17
“Automatizace běží v jiném čase, než čekáte. Který čas má pro firmu platit?”	AWS/GCP/Airflow/Kubernetes time-zone and interval documentation above	Current versions/dates above	Cross-provider documented behavior + editorial synthesis	Supported if rewritten as a design question, not universal failure claim	Keep/rewrite: “A schedule needs an explicit time contract: business period, local zone, UTC instant and elapsed duration are different things.” 9
“Jedna automatizace čeká na druhou. Kdo hlídá, že celý postup doběhl?”	Airflow dependency/DAG-state docs + end-to-end paper	Sources above	Documented workflow behavior + systems-design interpretation	Supported, with qualification	Keep/rewrite: “Define a single end-to-end acceptance state; individual green tasks do not establish business completion.” 4

Source-access qualifications

The Workflow Patterns Springer page exposed the abstract and bibliographic record but labeled the full article as subscription content; the claims here therefore stay within the accessible abstract/metadata. 1

The Saltzer/Reed/Clark paper was available as an MIT-hosted PDF and was visually inspected with page screenshots before using its argument. 2

The Pegasus publisher page exposed the abstract and study summary; this dossier does not claim details beyond that accessible scope. 14

No provider console, production deployment, service SLA measurement, billing record, incident database, private benchmark or customer account was accessed. Accordingly, provider documentation is treated as a documented contract/design claim, never as measured field reliability.

Contradictions, limitations and practical implications

Claims the evidence does not support

“Cron is unreliable; orchestration is reliable.” — Remove.
That framing is much too crude. Some schedulers expose retries, deadlines, deduplication hints, time zones and DLQs; Kubernetes and Google both document duplicate-delivery possibilities, but that says nothing about the relative incident rate of a well-designed one-script system versus an orchestrator. 6 An orchestrator also has operational dependencies of its own: Airflow uses a persistent scheduler and metadata database, and upgrades can require database migrations and backups. 4

“If the DAG is green, the report is correct.” — Contradicted.
Even Airflow’s own documented DAG-status rules can produce a successful DAG while an earlier internal task failed if terminal trigger rules are misconfigured. More fundamentally, an engine does not know the business semantics of the source version unless the workflow encodes them. 7

“UTC solves scheduling.” — Rewrite.
UTC removes ambiguity from instants and is a good representation for event timestamps, but it does not answer “06:30 according to which business’s wall clock?” or “what counts as the prior working day?” AWS demonstrates concretely that a 24-hour rate interval and a local-time cron schedule behave differently across DST. 9

“Every daily automation should use an orchestrator.” — Unsupported.
The literature and documentation establish capabilities, not such a threshold. For one serial workflow, putting every step in one executable materially reduces dependency complexity. Adding a ten-component orchestration platform solely to run one serial command can increase rather than reduce the number of things the team must own. Airflow’s documented scheduler/metadata database and migration requirements make that trade-off concrete for self-managed Airflow. 4

“Five cron jobs are equivalent to one five-step workflow.” — Usually false under this dossier’s requirements.
They become equivalent only after the individual jobs share durable dependency state, period/version correlation, locking, retries, reconciliation and whole-task acceptance. At that point, the team has effectively implemented a small orchestration layer of its own. That last characterization is an architectural interpretation, not a measured product result.

The point at which I would introduce an orchestrator

For this specific chain, I would begin with one sequential executable + durable run ledger rather than independent schedules. I would move to an orchestrator when one or more of these stops being exceptional and starts being normal operating behavior:

Signal	Why it changes the decision
Multiple branches or fan-out/fan-in	Dependency state becomes awkward to encode procedurally
Different steps require independent retry/timeout policies	Per-task lifecycle becomes first-class
Several historical periods can execute concurrently	Run identity, concurrency and operator control become harder
Frequent backfills/reprocessing	Native interval/run tooling gains operational value
Long waits on upstream events	Persistent workflow state becomes more valuable than a long-running process
Several engineers/teams operate the process	Standardized UI/history/ownership becomes leverage
Operators often ask “what is waiting on what?”	The observability benefit moves from convenience to requirement
The custom ledger starts acquiring schedulers, task queues and generalized dependency rules	You are building an orchestrator; buying/adopting one deserves serious consideration

Airflow’s explicit dependency scheduler, interval/catchup/backfill constructs and execution history are concrete examples of the facilities gained at that point. 4 The qualification is that self-managed Airflow also brings a database/scheduler lifecycle, whereas managed workflow engines can move some of that burden back to a provider. 16

What should remain outside the orchestrator

Regardless of technology, the following belong in the process/application contract:

business_date; source/version identity; raw immutability/checksum; idempotency semantics; what a “complete” report means; how stale data is rejected; and the late-report policy.

The orchestrator can persist and expose those values, but it cannot invent their business meaning.

Likewise, an AI agent should not be the authoritative scheduler, period selector, or completion oracle by default. A bounded AI component could summarize failure logs, classify incidents for operator triage, or propose a recovery action. The deterministic run ledger, period/version checks and acceptance predicate should remain authoritative. This is an editorial architecture recommendation; this dossier did not test an AI agent and found no empirical evidence requiring one.

Falsifiable comparison for a real team

A fair evaluation should test the same contract and failure injections, rather than comparing a fragile cron example with a carefully engineered orchestrator.

The proposed experiment—not performed here—is to implement:

System S: one scheduled script + durable ledger/lock/idempotency/reconciliation.

System O: the same stage functions and the same (B,v) acceptance contract under the candidate orchestrator.

Then inject identical cases: late source, duplicate invocation, crash after each committed stage, permission failure, timeout, stale source/version, scheduler outage, overlapping period, DST-crossing backfill, and manual replay.

Measure only observable outcomes such as:

\text{wrong accepted outputs}

\text{duplicate accepted outputs}

\text{missing periods undetected by deadline}

\text{recovery actions required per injected failure}

\text{time from failure injection to deterministic detection}

\text{time/steps required for handover to another operator}

\text{maintenance effort for upgrades/configuration changes}

No comparative result for those measures is claimed here. The test is useful precisely because it can falsify the recommendation: if the robust script handles the team’s real failure envelope with materially less ownership burden, orchestration is unnecessary. Conversely, if meeting the same requirements causes the script to grow a generalized task-state machine, backfill engine, queue, operator UI and dependency model, the “simple script” argument has largely disappeared.

Unresolved evidence gaps

The largest gap is empirical. The academic workflow literature provides formal/modeling foundations, while provider documentation provides feature contracts, but neither answers a practical question such as “At what workflow complexity does an orchestrator reduce net operating burden for a five-person analytics team?” The Pegasus paper reports a performance result for workflow restructuring in an astronomy application, which is interesting but not transferable as evidence of business-data workflow reliability or staffing outcomes. 14

Similarly, no evidence inspected here supports a universal claim that orchestration lowers mean time to recovery, incidents, engineering hours, or cost. Those would require either controlled comparative experiments or carefully scoped operational datasets.

The provider documents also differ in what they promise. AWS precisely documents a skip-on-spring/once-on-fall DST policy for EventBridge Scheduler, whereas Google’s Cloud Scheduler documentation warns more generally of wall-clock anomalies. Those statements are not contradictory because they describe different products. They are evidence against assuming a universal “cron DST behavior.” 9

Timezone rule freshness remains an operational dependency. Airflow specifically warns that Pendulum’s database may lag the IANA database unless configured otherwise. 11 Therefore both the scheduler and the application/runtime timezone data belong in the system’s freshness review.

Reusable editorial angles, assets and freshness triggers

The strongest article angle is not “cron versus Airflow.” That invites an unhelpfully tool-centric debate. The evidence supports several more distinct treatments.

“Your automation ran successfully. Your report can still be wrong.”
Use the late-source/stale-report scenario to distinguish trigger success, task success and business acceptance. The academic anchor is end-to-end correctness; Airflow’s own leaf-status warning supplies a useful product-level counterexample to equating workflow green with business correct. 2

“A schedule is not a definition of time.”
Build around the four-way distinction between business period, local civil time, UTC instant and elapsed duration. AWS’s documented rate(1 days) versus local cron behavior is a particularly concrete illustration, alongside Google Scheduler’s wall-clock warning. 9

“When does a script become an orchestrator?”
Start from the robust one-script baseline rather than a straw-man cron script. Add requirements one at a time—durable state, independent retries, backfills, overlapping runs, cross-team visibility—and identify the point at which continuing to build the control plane internally ceases to be simpler. Airflow supplies a concrete reference architecture, while its upgrade documentation prevents the piece from treating orchestration as free infrastructure. 4

“Stop scheduling dependencies; correlate them.”
The important transformation is from “run B at 07:00 because A probably finished” to “run B for exact (business_date, source_version) when A’s accepted state exists.” Lamport’s causal-order framing provides the formal intellectual anchor, with the warehouse application clearly labeled as inference. 5

“One green status for the whole business task.”
A useful management-facing version: five green subprocesses are weaker evidence than one explicit acceptance predicate for the result customers actually consume. The end-to-end paper and Airflow status semantics support the distinction. 2

Reusable assets

The downloadable research asset contains the actual synthetic contract, dependency table, acceptance cases and executable tests:

workflow_orchestration_evidence_asset.zip [original file unavailable]

It is portable in the sense that it uses Python’s standard library only. The captured run records 12 passing synthetic tests. It is deliberately not production-ready and does not contain provider-specific deployment code.

An additional useful publication asset would be a single state diagram:

period due → waiting_source → raw_preserved → ingested → transformed → report_rendered → accepted

with failure branches into blocked_source_late, failed_retryable, and failed_terminal, and with (B,v) printed on every edge. That diagram is proposed, not supplied as a separate image file in this dossier.

Freshness triggers

This dossier should be rechecked when any selected scheduler/orchestrator materially changes scheduling, retry, catchup/backfill or timezone semantics; when the deployed Airflow major/minor version changes; when Kubernetes CronJob semantics/version changes; or when cloud provider documentation changes. Airflow upgrades can include metadata-database migrations, so version upgrades are themselves an operational review trigger. 16

It should also be refreshed following relevant IANA timezone-rule changes or changes in national/EU daylight-saving policy. The scheduler’s timezone database and the application’s timezone database should be reviewed independently because Airflow already documents a potential difference between Pendulum’s bundled data and IANA/system data. 11

The Google Cloud Scheduler source is particularly fresh at this snapshot—last updated 2026-10-07, three days before inspection—while Kubernetes’ inspected CronJob page was last modified 2026-05-13. 10 AWS’s inspected scheduler pages and several Airflow pages do not expose a comparable page-publication date in the retrieved material; their product/version scope and the 2026-10-10 inspection date should therefore remain attached whenever their behavior is quoted.

The durable conclusion is narrower than any product recommendation: design the business period, dependency identity, failure states, reconciliation and acceptance condition first. A simple scheduled script remains genuinely simple only while it can satisfy that contract without growing an improvised workflow engine.

Portable citation index

[1] Workflow Patterns | Distributed and Parallel Databases | Springer Nature Link

[2] web.mit.edu

[3] CronJob | Kubernetes

[4] Scheduler — Airflow 3.3.2 Documentation

[5] Time, Clocks and the Ordering of Events in a Distributed System - Microsoft Research

[6] Manage cron jobs  |  Cloud Scheduler  |  Google Cloud Documentation

[7] Dag Runs — Airflow 3.3.2 Documentation

[8] Workflows | Google Cloud

[9] Schedule types in EventBridge Scheduler - EventBridge Scheduler

[10] Cron job format and time zone  |  Cloud Scheduler  |  Google Cloud Documentation

[11] Time Zones — Airflow 3.3.2 Documentation

[12] Retry jobs  |  Cloud Scheduler  |  Google Cloud Documentation

[13] Configuring a schedule’s dead-letter queue in EventBridge Scheduler - EventBridge Scheduler

[14] Pegasus: A Framework for Mapping Complex Scientific Workflows onto Distributed Systems - Deelman - 2005 - Scientific Programming - Wiley Online Library

[15] Timetables — Airflow 3.3.2 Documentation

[16] Upgrading Airflow® to a newer version — Airflow 3.3.2 Documentation

[17] About dbt freshness command | dbt Developer Hub

Workflow Orchestration Versus Simple Scheduled Scripts: Practitioner Evidence Dossier

Research snapshot: 2026-10-10
Perspective: Practitioner
Decision supported: Choose between a scheduled script/native scheduler and a workflow orchestrator for the same bounded daily data/reporting process and the same failure requirements.
Evidence boundary: Public sources and synthetic fixtures only. No private production systems were accessed. No vendor service, Airflow cluster, dbt project, warehouse, or cloud scheduler was executed. A portable standard-library Python acceptance harness was executed locally in this research session; its scope and limitations are stated below.

Executive answer and decision boundary

For the bounded process in scope—daily source export → raw preservation → ingestion → dbt/warehouse transformation → business report—I would not adopt an orchestrator merely because the workflow has five steps.

I would first make the process deterministic: define the reporting period independently of execution time, require an exact source version, preserve raw input, give every run a durable correlation key, make stages safe to replay or reconcilable, define a deadline, and establish one explicit whole-workflow acceptance state. Only then choose the implementation.

For one team, one mostly linear workflow, modest concurrency, and infrequent backfills, my default would be a managed/native scheduler or a host timer invoking one small coordinator with durable state, rather than Airflow. The coordinator needs a database or equivalent durable ledger, a lock/lease, exact period/version checks, stage checkpoints, retry rules, timeout handling, and reconciliation. This is materially more than cron → shell script, but it can remain substantially smaller operationally than running a general-purpose orchestrator. Google’s own reliability discussion reaches the same architectural boundary from the opposite direction: ordinary single-machine cron is essentially fire-and-forget, but once reliability demands partial-failure recovery, duplicate protection, failover, and state tracking, substantial durable scheduling state becomes necessary. 1

I would move to an orchestrator such as Airflow when the operational problem itself has become a workflow-management problem: many dependencies, parallel branches, frequent backfills, multiple operators or teams, per-stage retry/timeout requirements, handover through a common UI, and a need to inspect historical runs without rebuilding that tooling. Airflow explicitly represents DAG runs, task dependencies, task states, data intervals, catchup, and backfill. 2

The strongest conclusion is therefore:

The decision threshold is not “more than one step.” It is how much durable workflow state, dependency correlation, recovery logic, historical operation, and human handover you otherwise have to build yourself.

There are two important qualifications.

First, an orchestrator does not automatically make the business process reliable. Airflow itself warns that a DAG can be marked successful despite an intermediate failure if a successful leaf task uses an all_done trigger rule. A separate business-acceptance check is therefore still needed. 2

Second, orchestration introduces another production system. Airflow’s own production documentation requires an external metadata database rather than its test-only SQLite default, discusses executor and distributed logging configuration, explicitly recommends scheduler health monitoring because scheduler hangs are reported, and requires operational care around upgrades and database migrations. 3

Decision at a glance

Situation	Practitioner recommendation	Why
One genuinely independent periodic command; missing one invocation is harmless	Simple host timer/cron-style scheduler	Workflow state is not actually required.
One bounded linear business workflow, one owner, but exact period/version, retries, duplicate suppression and recovery matter	Scheduler + small durable coordinator	You need workflow semantics, but not necessarily a workflow platform.
Host availability itself is an undesirable trigger failure domain	Managed/native scheduler + durable coordinator	Removes a single scheduler host while leaving business-state logic in your application. Google Cloud Scheduler, for example, is an at-least-once invocation service with configurable retries. 4
Frequent backfill, branching/parallel dependencies, multiple workflow owners, substantial operational handover	Orchestrator	Its durable run/task model and operating interface start replacing meaningful custom infrastructure. Airflow has first-class run intervals, catchup and backfill. 2
“We need Airflow because cron is unreliable”	Rewrite the decision statement	Cron implementations vary, and sophisticated schedulers can be highly reliable; the missing property is usually end-to-end workflow state, not cron syntax itself. Google built a strongly consistent distributed cron service, while systemd and cloud schedulers have their own recovery semantics. 1
“Airflow says green, therefore the business report is correct”	Reject	Platform completion and business completion are different assertions. Airflow’s documented leaf-state behavior demonstrates why. 2

Principal uncertainty

I found no controlled or quasi-experimental primary study comparing a minimal durable script with Airflow on this exact bounded workflow under identical failure injections. The strongest directly applicable evidence is therefore architectural: official implementation documentation, first-party operating guidance, and Google SRE’s attributable experience with periodic scheduling and data pipelines. Google explicitly describes periodic pipelines as useful and regularly used while also reporting that its SRE experience found the model fragile as scale and complexity change. That is valuable practitioner evidence, but it is not an experimental estimate of an “Airflow reliability uplift” or return on investment. 5

No universal cost, ROI, incident-rate reduction, or maintenance saving is claimed in this dossier.

Bounded process and operational contracts

Recognizable business process

The dossier uses the same process for every alternative:

Source system → immutable/raw preservation → ingestion → warehouse/dbt transformation → business report → explicit acceptance

This is a synthetic process design, not a reported customer implementation.

Element	Contract for this dossier
Business owner	Person accountable for receiving the correct report by its declared deadline.
Technical owner	Data/analytics team owning the end-to-end workflow, including recovery—not merely the individual transformation jobs.
Trigger	A local-calendar trigger, exemplified as 06:30 in a declared IANA time zone. Triggering initiates an attempt; it does not prove that data for the intended period exists.
Source input	Manifest plus export: reporting_period_id, source_version, produced_at, checksum, schema version, payload.
Raw preservation	Immutable or uniquely versioned copy identified by the same period/version key.
Ingestion	Loads only the explicitly accepted raw artifact.
Transformation	dbt/warehouse transformation against the correlated input. No dbt-specific reliability result is assumed here.
Report publication	Produces a report carrying its reporting-period/version identity.
Business successful end state	The correct period and source version have passed required stages and checks and have been explicitly accepted by the deadline.
Important exceptions	Source late/missing; wrong reporting period; changed source version; duplicate trigger; overlapping run; task retry; partial external side effect; scheduler/host interruption; transformation failure; report publication failure; deadline miss; backfill/replay; DST transition.

The process deliberately rejects the common shortcut “whatever file is latest at execution time.” That shortcut couples business semantics to wall-clock execution and makes a technically successful run capable of using stale input. Google’s distributed-cron design similarly concludes that a logical launch needs an unambiguous identity—Google uses scheduled launch time in its context—and that recovery from uncertain partial operations requires either idempotency or a way to look up whether the external operation completed. 1

Simplest manual/native baseline

Before adding automation, the smallest correct process is manual:

An operator determines the intended reporting period, verifies that the matching source/version is actually available, preserves that exact artifact, runs ingestion, runs the transformation, checks the output’s period/version and required quality conditions, publishes the report, and records final acceptance. When an input is absent or ambiguous, the operator stops rather than silently substituting another period.

That baseline matters because it exposes a process-design problem before turning it into an automation problem. If people cannot state which period is expected, which version wins, what “done” means, and how to resolve a partly completed run, an orchestrator merely automates an ambiguous process.

Google’s data-integrity guidance puts the emphasis on what users actually receive, and on proactive detection plus rapid repair/recovery, rather than treating infrastructure activity itself as the outcome. 6

Process-design recommendation: remove or standardize the following before debating cron versus Airflow:

latest.csv → exact period/version manifest
“run every morning” → schedule/time-zone contract
“job passed” → business acceptance condition
“retry everything” → retry/reconcile policy per side effect
“run it again” → explicit replay/backfill identity
“John knows how to fix it” → recorded recovery state and ownership

These are editorial recommendations derived from the documented failure patterns; they are not measured effects.

Time and period contract

The crucial distinction is between business period, local civil/calendar schedule, and elapsed duration.

IANA’s time-zone database exists specifically because local civil time, UTC offsets, and daylight-saving rules vary and are periodically changed by political decisions. The latest IANA release at the snapshot date was 2026e, released 2026-09-29. 7

A reusable contract for this workflow is:

Field	Proposed contract	Why
reporting_period_id	Explicit business identifier, for example 2026-10-05; never inferred downstream from “now”.	Dependency correlation survives delay and replay.
business_zone	Named IANA zone such as Europe/Prague or America/New_York.	An offset such as +02:00 does not encode future DST rules. IANA maintains these rules over time. 7
period_start, period_end	Defined in business semantics, then converted to UTC for storage/comparison.	A local calendar day can span 23, 24 or 25 elapsed hours around DST; the acceptance harness below exercises a 25-hour Prague day.
delivery_date	Separate from reporting_period_id where the report covers the previous day/business period.	Prevents schedule date from becoming data identity.
Local schedule	Example: 06:30 Europe/Prague on the intended delivery calendar.	“06:30 local tomorrow” is a civil-calendar requirement, not “86,400 seconds later.”
Elapsed timeout	Example: 90 min measured as elapsed time.	A timeout is a duration; it normally should not lengthen or shorten because a clock changes.
Business calendar	Versioned rule/table, e.g. CZ_REPORT_CAL_V1 or US_REPORT_CAL_V1; weekends/holidays explicitly modeled.	Scheduler weekday syntax is not a complete business-calendar definition.
Correlation key	(workflow_id, reporting_period_id, source_version)	Duplicate invocation can map to one logical business attempt.
Source readiness	Exact manifest for the requested period/version; not “some file exists”.	Prevents stale-state success.
Completion deadline	Explicit local instant, e.g. 08:00 Europe/Prague on delivery date, converted to UTC at evaluation.	Makes business completion externally observable.
Accepted state	period_ok ∧ version_ok ∧ required_artifacts_present ∧ quality_checks_ok ∧ accepted_at ≤ deadline	Makes “whole workflow done” stronger than task/process exit codes.

A useful notation is:

\text{business\_success}(P,V)=
\text{period\_ok}
\land
\text{version\_ok}
\land
\text{required\_stages\_complete}
\land
\text{report\_checks\_ok}
\land
(t_{\text{accepted}}\le t_{\text{deadline}})

No success rate is implied by this formula; it defines the proposed acceptance contract.

For time arithmetic:

\Delta t_{\text{elapsed}}
=
UTC(t_2)-UTC(t_1)

while the next local-calendar occurrence is obtained by evaluating the civil-time rule in the named time zone. These are deliberately different operations.

That difference is implemented in real scheduling products. systemd documents OnCalendar= as a real-time/wall-clock calendar timer, while OnActiveSec, OnBootSec, and OnUnitActiveSec are monotonic timers independent of wall-clock time zones. 8 Airflow likewise documents different DST behavior between timezone-aware cron scheduling and duration-based timedelta scheduling: cron follows the timezone’s DST rules, while elapsed-duration scheduling does not adjust subsequent runs in the same way. 9 Google Cloud Scheduler explicitly says schedules can be evaluated in a selected time zone using wall-clock time and warns that DST can produce anomalies such as a local time occurring twice; it recommends UTC when an exact elapsed cadence is the actual requirement. 10

This directly supports qualifying the proposed article claim “Automation runs at a different time than you expect. Which time should apply to the business?” The useful distinction is not merely “set the timezone.” It is:

Does the business mean a local calendar occurrence, a UTC instant, or a duration since the previous event?

Those contracts diverge at DST and after civil-time rule changes.

Dependency state, timeout and recovery contract

For “one automation waits for another,” the dependency should be the right output for the right logical period/version, not merely “the other job most recently succeeded.”

State	Observable condition	Timeout/deadline behavior	Recovery/reconciliation
EXPECTED	Run identity declared; exact source not yet checked.	Transition immediately to source check.	None.
WAITING_INPUT	No exact (period, version) manifest yet.	Wait using an elapsed timeout; do not execute downstream against latest.	Poll/event-wake the same logical run.
WAITING_LATE	Source-wait threshold exceeded.	Alert owner; business deadline may still be open or already missed.	Keep logical run recoverable; late arrival reopens/resumes by explicit policy.
READY	Exact manifest/version validated.	Downstream execution may start.	Immutable correlation information is now fixed.
RUNNING(stage)	Stage owns the same correlation key.	Each stage may have its own execution timeout.	Retry only where operation is safe or reconciled.
RETRYABLE_FAILURE	Known failure and replay semantics defined.	Retry budget/backoff applies.	Same logical run; do not silently create a new business period.
PARTIAL_UNKNOWN	External mutation may have happened, but acknowledgement was lost.	Automatic blind retry is unsafe.	Look up deterministic artifact/job ID; either continue from observed state or execute an idempotent operation. This is the same fundamental choice identified by Google’s distributed-cron design. 1
REJECTED_WRONG_PERIOD	Available data does not match expected period/version.	Never count as downstream success.	Locate/correct source; controlled replay.
CANCELED	Operator/policy stopped work.	Cancellation is not business completion.	Reconcile external side effects before restart.
LATE_ACCEPTED	Correct data/report eventually accepted after deadline.	Technical correctness recovered, but deadline requirement failed.	Retain separately from on-time success for operations review.
ACCEPTED	Exact period/version and every acceptance condition satisfied by deadline.	Terminal business success.	Immutable audit/reconciliation record.

Airflow’s task model supplies explicit dependency and task-instance state, and its DAG-run model supplies a run identity and data interval. 11 But the proposed ACCEPTED state is an application/business construct, not an Airflow default. Airflow’s own leaf-node warning is precisely why I would keep a deterministic acceptance task or external ledger as the final authority. 2

Evidence synthesis across the alternatives

The same requirements expose a false cron-versus-orchestrator binary

There are really four relevant designs.

Capability	Manual baseline	Host scheduler + durable coordinator	Managed/native scheduler + durable coordinator	Representative orchestrator: Airflow
Scheduling	Human	systemd/cron-style schedule	Provider scheduler, e.g. Cloud Scheduler	Built into workflow platform
Local calendar / DST	Human interprets contract	Scheduler-specific; systemd distinguishes calendar and monotonic timers. 8	Provider-specific; Cloud Scheduler uses wall-clock timezone semantics and documents DST risk. 10	Timezone-aware cron/data intervals; DST behavior documented. 9
Dependency ordering	Operator	Coordinator code	Coordinator code	DAG dependencies
Exact period/version correlation	Operator checks	Must be application code/state	Must be application code/state	Can be carried in run/data context, but business version validation remains application logic
Durable workflow state	Human log/checklist	Small DB/ledger you own	Small DB/ledger you own	Airflow metadata database and task/run records
Retry	Manual	Application policy	Scheduler can retry invocation; application still owns stage semantics	Task-level retries/state
Duplicate protection	Human	Unique key + idempotency/reconciliation	Required because provider can redeliver	Still needed for external side effects
Overlap	Human coordination	Lock/lease	Lock/lease plus any provider control	Platform concurrency controls plus application idempotency where needed
Backfill	Manual repeat	Loop over explicit period keys	Same	First-class catchup/backfill concepts 2
Whole-business completion	Human sign-off	Explicit acceptance row/check	Explicit acceptance row/check	Explicit acceptance task/check; DAG green alone is insufficient
Historical operations	Manual records	Whatever ledger/log UI you build	Provider invocation history + your ledger	Native run/task histories and UI
Host scheduler outage	Human unaffected	Local host is failure domain unless timer/platform supplies recovery	Provider owns scheduler availability characteristics	Airflow control plane must itself be operated
Platform maintenance	Minimal software	OS/runtime/dependencies/state DB/monitoring	Target app/state/IAM/provider config	Metadata DB, executor, logs, scheduler, DAG deployment, upgrades and health monitoring. 3
Best fit	Very low frequency / judgment-heavy	Small bounded workflow with one owner	Same, when removing local scheduler-host dependency is valuable	Repeated operational workflow complexity justifies dedicated control plane

What a “simple script” really means under the requested requirements

A bare scheduled command is genuinely simple only when failure semantics are simple. Google’s first-party description of conventional cron is unusually useful here: it characterizes ordinary crond launches as fire-and-forget, with only configuration needing persistence, and notes that a machine outage prevents both the scheduler and its jobs from running. 1

For the user’s required failure envelope, the script design needs at minimum:

durable run key
+ exact source manifest validation
+ stage state/checkpoints
+ single-run lease
+ idempotent or reconcilable side effects
+ elapsed wait timeout
+ deadline alarm
+ replay/backfill command
+ final reconciliation
+ logs/metrics/alerting

At that point, it is fair to say that you have built a tiny workflow engine. That is not automatically a mistake. For one linear pipeline it may be the better engineering trade-off because its domain can remain extremely small and legible.

Google’s distributed-cron chapter is strong counterevidence to the idea that “cron can never be reliable.” Google describes building a robust distributed cron service through replicated state, consensus, unique launch identity and partial-failure recovery. It is simultaneously evidence that reliability does not come from a five-field schedule expression; it comes from state and recovery architecture around scheduling. 1

What a native managed scheduler buys

Google Cloud Scheduler is a useful representative because its current documentation makes the boundary explicit. It invokes an HTTP, Pub/Sub, or App Engine target and uses at-least-once delivery, so the target must tolerate occasional duplicate invocation. It supports retry with exponential backoff for unsuccessful delivery and exposes job/scheduled-time information that can help deduplicate retry attempts. 4

That is a meaningful improvement over “this particular VM must be alive at 06:30,” but it does not by itself establish that raw preservation, ingestion, transformation, report publication and business acceptance all completed for the same reporting period. That conclusion is an architectural inference from the scheduler’s documented invocation scope, not a negative vendor claim. 4

Cloud Scheduler also demonstrates why provider semantics must be inspected rather than generalized from the word “cron.” Its documentation says disabling and later re-enabling its API can cause missed jobs to execute immediately, and its wall-clock timezone behavior carries DST caveats. 10

Kubernetes makes the same non-universality even clearer. Current CronJob documentation says a Job is created approximately once for each scheduled execution and that circumstances can yield two Jobs or no Job; it consequently recommends idempotent jobs. It also offers startingDeadlineSeconds, concurrencyPolicy, and a named .spec.timeZone, with provider-specific semantics for missed executions and overlap. 12

So the right question is not “does cron retry?” It is:

What does this specific scheduler guarantee about trigger delivery, missed schedules, duplicate schedules, time zones and overlap—and which remaining guarantees belong to the application?

What an orchestrator buys

Airflow 3.3.2 provides machinery that directly maps to several requirements in this dossier. A DAG run is a distinct workflow instantiation; tasks have dependency state; scheduled runs operate on data intervals; catchup can materialize missing intervals; and backfill/re-running is an explicit concept. 2

That reduces the amount of generic operational workflow machinery a team has to invent. In particular, the value becomes high when someone frequently needs to answer questions such as:

“Which period failed?”
“Which upstream task blocks it?”
“What was already successful?”
“Can only this stage be retried?”
“Which historical periods must be backfilled?”
“Is another attempt currently running?”
“What logs belonged to that task attempt?”

Those are exactly the kinds of state that ordinary fire-and-forget cron does not retain, while Airflow deliberately models workflow/task history. 1

But Airflow only moves complexity; it does not eliminate it. Its production guidance calls for a production metadata database, executor decisions, DAG/config distribution, durable logging when workers are disposable, scheduler health checking, and upgrade procedures. Airflow explicitly notes reported scheduler hangs and advises heartbeat-based health checks. 3

This is the maintenance trade:

\text{custom coordination burden}
\quad \leftrightarrow \quad
\text{orchestrator control-plane burden}

There is no evidence here establishing a universal crossover point in number of jobs, employees, or dollars.

Local schedule versus elapsed interval

The draft claim “Automation runs at a different time than you expect” is strongly supported, but the useful version should be precise.

systemd explicitly separates monotonic timers from wall-clock OnCalendar timers. It also supports IANA-format timezone names in calendar expressions. 8 Its Persistent=true behavior for calendar timers stores the last trigger information and can immediately trigger a service after the timer was inactive if at least one occurrence was missed. 8 That is a specific systemd behavior—not a universal property of “cron.”

Airflow similarly says that timezone-aware cron schedules follow daylight-saving changes, whereas a timedelta schedule behaves as an elapsed-duration schedule for subsequent runs. 9

Google Cloud Scheduler says its chosen timezone is interpreted using wall-clock time, warns about DST anomalies such as a repeated local time, and recommends UTC where precise cadence matters more than a fixed local clock reading. 10

Therefore:

Keep: “Which time should apply to the business?”

Rewrite the explanation as: “Specify whether the requirement is a local civil/calendar time, a UTC instant, or an elapsed interval. They are not interchangeable around DST.”

The Czech and US architectural conclusions do not materially differ. Europe/Prague and America/New_York are simply different named civil-time rule sets and their transition dates need not coincide. Current time-zone rules should come from maintained IANA data rather than hard-coded offsets. 7

Waiting for another automation

The second target claim—“One automation waits for another. Who watches that the whole process finished?”—is also supported, but I would sharpen it:

“A downstream process should wait for the correct upstream period/version, not just for an upstream process to have been green recently. One explicit completion authority should decide whether the entire business task is done.”

Airflow’s data-interval concept helps maintain temporal run identity, but it does not automatically validate arbitrary source-version semantics. 2 Google’s distributed-cron account independently emphasizes unique launch identity and explicit resolution of uncertain partial operations. 1

Airflow also provides a useful warning against outsourcing the business definition of “done” to platform status: a successful all_done leaf can cause a DAG run to be considered successful even when an intermediate task failed. 2

I would therefore make the final task deterministic:

accept_period(period_id, source_version):
    assert exact source manifest accepted
    assert raw artifact exists and checksum matches
    assert ingestion for same period/version completed
    assert transformation for same period/version completed
    assert report carries same period/version
    assert required quality checks pass

    if now <= deadline:
        record ACCEPTED
    else:
        record LATE_ACCEPTED

The orchestration platform may schedule that function. It should not replace what the function means.

Worked failures, recovery, and executed synthetic asset

Worked example: late source plus stale previous data

Label: synthetic example, not a reported customer incident.

Assume the report for reporting period 2026-10-05 is due at 08:00 Europe/Prague on 2026-10-06. The normal automation trigger is 06:30 Europe/Prague. Expected source version is export-v7.

At 06:30, the landing location contains yesterday’s previously processed export but not export-v7 for the requested reporting period.

A naive implementation might be:

latest=$(ls -t incoming/*.csv | head -1)
load "$latest"
dbt build
publish_report

Every command can return exit code 0 while the business result is stale. This is a hypothetical failure pattern, not measured vendor behavior.

The contract-based implementation instead starts:

run_key =
  ("daily_business_report", "2026-10-05", "export-v7")

06:30 → WAITING_INPUT

It refuses to run ingestion unless the manifest says exactly:

{
  "reporting_period_id": "2026-10-05",
  "source_version": "export-v7",
  "schema_version": "v1",
  "checksum": "...",
  "produced_at": "..."
}

Suppose the proper source arrives at 07:10. The existing logical run—not a newly invented reporting period—resumes:

WAITING_INPUT
→ RAW_PRESERVED
→ INGESTED
→ TRANSFORMED
→ REPORT_PUBLISHED
→ ACCEPTED at 07:xx

Because acceptance occurred before 08:00, this synthetic case satisfies the defined business deadline.

If the source did not arrive within a 90-minute elapsed wait, the proposed state becomes WAITING_LATE; downstream work stays blocked and the technical owner is alerted. The exact 90-minute value is a synthetic assumption, not a recommended universal timeout.

Partial failure and reconciliation

Now suppose the process crashes immediately after writing the raw object but before its acknowledgement reaches the coordinator.

There are only two safe generic recovery patterns:

1. make raw preservation idempotent for a deterministic artifact key; or
2. ask the raw store whether that exact artifact exists and matches the expected checksum before trying again.

Google’s distributed-cron implementation reaches the same general conclusion for uncertain external operations: recovery requires either idempotent operations or the ability to look up their state unambiguously. 1

A deterministic artifact scheme might be:

raw://daily_business_report/
    reporting_period=2026-10-05/
    source_version=export-v7/
    payload.csv
    manifest.json

A retry then does not ask “did yesterday’s process run?” It asks “does the artifact for this exact logical run exist in the expected state?”

Host/scheduler interruption

For a host timer, recovery depends on the concrete implementation. systemd’s Persistent=true can catch up a missed OnCalendar occurrence when the timer becomes active again; systemd also documents that if several calendar occurrences elapsed while a system was continuously asleep, they result in a single service activation on resume rather than one activation for every elapsed occurrence. 8

That is why the coordinator should perform period reconciliation after restart:

for each expected reporting period up to now:
    if no ACCEPTED or explicitly terminal record:
        enqueue/recover that period

The scheduler’s missed-run behavior becomes a wake-up mechanism, not the authoritative ledger of which business periods are complete.

Airflow can provide this period materialization through catchup/backfill: with catchup enabled it can create DAG runs for intervals not previously run, while the current default described in Airflow 3.3.2 is not to create all missed historical intervals automatically. 2

Replay crossing a DST transition

A backfill should therefore iterate business keys:

2026-10-24
2026-10-25
2026-10-26

rather than calculating:

last_timestamp + 24h
last_timestamp + 48h
...

The executed synthetic harness demonstrated the distinction for Europe/Prague:

06:30 local on 2026-10-24 -> 04:30 UTC
06:30 local on 2026-10-25 -> 05:30 UTC
06:30 local on 2026-10-26 -> 05:30 UTC

It also verified that the local 2026-10-25 Prague calendar day spans 25 elapsed hours in the runtime time-zone data. This is synthetic execution using Python’s zoneinfo; the runtime’s underlying tzdata package version was not independently proven to be IANA 2026e. IANA itself reports 2026e as the current public database release at the research snapshot. 7

For the US variant, the same harness found a nonexistent 02:30 America/New_York on 2026-03-08 and two distinct UTC instants for 01:30 America/New_York on 2026-11-01. These are executed synthetic fixtures, not a claim that every scheduler treats those local times identically. Provider behavior must be separately checked; Cloud Scheduler, Airflow and systemd document different scheduling APIs and recovery rules. 10

Executed acceptance harness

A self-contained Python 3.9+ harness using only the standard library was created and executed in this research session:

Download the portable acceptance harness [original file unavailable]

It contains an SQLite-backed miniature coordinator, deterministic run/stage identities, leases, manifest checks, reconciliation, IANA-zone handling through zoneinfo, and the test fixtures.

The harness process exited with code 0 and all 15 synthetic assertions passed. The visible notebook environment also emitted an unrelated spreadsheet-runtime warmup warning after the test output; it did not originate in the harness and did not alter its exit status.

Acceptance case	Executed?	Observed synthetic result
Prague nonexistent DST local time	Yes	2026-03-29 02:30 produced no valid UTC instant
Prague repeated DST local time	Yes	2026-10-25 02:30 produced two UTC instants
New York nonexistent DST local time	Yes	2026-03-08 02:30 produced no valid UTC instant
New York repeated DST local time	Yes	2026-11-01 01:30 produced two UTC instants
24 elapsed hours versus next 06:30 local	Yes	Across Prague fall-back, 24 elapsed hours reached 05:30 local; next local 06:30 was 25 elapsed hours later
25-hour local business day	Yes	Prague 2026-10-25 period measured 25 elapsed hours
Missing source at schedule time	Yes	Stayed WAITING_INPUT; no false success
Late source before deadline	Yes	Same logical run resumed and reached ACCEPTED
Duplicate invocation	Yes	Existing accepted run was not repeated
Concurrent overlap	Yes	Second holder returned OVERLAP_BLOCKED
Yesterday/wrong-period data	Yes	Returned REJECTED_WRONG_PERIOD
Process interruption after raw preservation	Yes	New coordinator process reopened same SQLite ledger and resumed without duplicating raw stage
Input wait beyond 90 min synthetic timeout	Yes	Returned WAITING_LATE
Backfill across Prague DST	Yes	Distinct business keys retained despite UTC-offset change
Versioned synthetic business calendar	Yes	Weekend/holiday lookup used explicit fixture data

Not executed: Cloud Scheduler duplicate delivery, Kubernetes CronJob duplicate/missing creation, systemd shutdown/restart recovery, Airflow catchup/backfill, Airflow scheduler death, task heartbeat recovery, Airflow upgrades, dbt executions, warehouse writes, report publication, or any private/production system.

Those behaviors are represented only where documented by primary sources. The harness must therefore not be presented as a vendor benchmark or operational customer result.

Claim-to-source evidence table

The table below separates documented behavior, attributable reported practice, and editorial implications. “Supported” means the cited primary source directly supports the factual core; it does not mean every possible implementation behaves identically.

Claim / decision point	Primary source and direct URL	Source date / version	Exact inspected scope	Evidence type	Status	Editorial advice
Traditional single-machine cron is essentially fire-and-forget and a scheduler-host outage prevents launches.	Google SRE, Distributed Periodic Scheduling with Cron: https://sre.google/sre-book/distributed-periodic-scheduling/ 1	Book copyright 2017; chapter notes partial prior publication in ACM Queue, Mar 2015	“Reliability Perspective,” especially discussion of single-machine failure domain and launch tracking	Attributable primary company operating/design account	Supported within Google’s discussion of conventional cron	Keep, qualify: say “traditional/simple cron implementation,” not every cron-like service
Reliable recovery from an uncertain partial operation requires either idempotence or unambiguous state lookup.	Same Google SRE chapter 1	2017 / prior 2015 material	“Resolving partial failures,” particularly the two recovery conditions	Architecture pattern from primary reported implementation	Supported	Keep; central design principle
Periodic pipelines can be useful but become operationally fragile as scale/workload/depth changes.	Google SRE, Data Processing Pipelines: https://sre.google/sre-book/data-processing-pipelines/ 5	2017 book	“Challenges with the Periodic Pipeline Pattern”; Google says it uses periodic pipelines and reports SRE experience of fragility under organic growth/change	Attributable reported practice, not controlled experiment	Supported but context-dependent	Qualify; do not turn into “periodic pipelines are inherently unreliable”
User-visible correctness/recoverability matters independently from mere service activity.	Google SRE, Data Integrity: https://sre.google/sre-book/data-integrity/ 6	2017 book	Definition of integrity and discussion of proactive detection plus rapid repair/recovery	Primary company reliability guidance	Supported as design principle	Keep as support for business-level acceptance
systemd distinguishes elapsed/monotonic timers from local wall-clock calendar timers.	systemd upstream source, systemd.timer.xml: https://github.com/systemd/systemd/blob/main/man/systemd.timer.xml 8	main branch snapshot; stable publication date not exposed; inspected 2026-10-10	OnActiveSec, OnBootSec, OnUnitActiveSec, OnCalendar	Provider/upstream software documentation	Supported	Keep; useful concrete implementation, do not generalize to all cron
systemd can persist and catch up a missed calendar timer after inactivity.	Same systemd upstream source 8	Main snapshot, inspected 2026-10-10	Persistent=	Provider/upstream documentation	Supported for systemd OnCalendar	Keep, narrowly scoped
systemd calendar expressions can name IANA-format zones.	systemd upstream systemd.time.xml: https://github.com/systemd/systemd/blob/main/man/systemd.time.xml 13	Main snapshot, inspected 2026-10-10	“Calendar Events,” timezone syntax	Provider/upstream documentation	Supported	Keep
Cloud Scheduler can deliver more than once; target must tolerate duplicates; unsuccessful delivery can be retried.	Google Cloud, About Cloud Scheduler: https://docs.cloud.google.com/scheduler/docs/overview 4	Updated 2026-10-07; inspected 2026-10-10	Delivery guarantees, retries, scheduled-time/job metadata	Provider documentation	Supported	Keep; strong argument for idempotent target
Cloud Scheduler wall-clock scheduling can have DST anomalies; UTC is preferable where exact cadence is intended.	Google Cloud, Configure cron job schedules: https://docs.cloud.google.com/scheduler/docs/configuring/cron-job-schedules 10	Updated 2026-10-07; inspected 2026-10-10	Time zones / daylight-saving-time section	Provider documentation	Supported for Cloud Scheduler	Keep, qualify; do not present as universal cron behavior
Kubernetes CronJob can create two Jobs or no Job in some circumstances and advises idempotent jobs.	Kubernetes, CronJob: https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/ 12	Last modified 2026-05-13; inspected 2026-10-10	“Job creation,” plus deadline/concurrency/time-zone sections	Upstream project documentation	Supported	Keep as counterexample to exactly-once assumptions
Airflow associates workflow runs with data intervals and supports catchup/backfill.	Apache Airflow 3.3.2, Dag Runs: https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/dag-run.html 2	Version 3.3.2 stable docs; page date not exposed; inspected 2026-10-10	“Data Interval,” “Catchup,” rerun/backfill behavior	Provider/open-source project documentation	Supported	Keep; strong differentiator from bare scheduler
Airflow DAG green is not necessarily equivalent to business success.	Same Airflow DAG Runs documentation 2	Airflow 3.3.2	“Dag Run Status” note on successful all_done leaf despite an intermediate failure	Project documentation / explicit counterexample	Supported	Keep prominently
Timezone-aware cron and elapsed/timedelta schedules have different DST behavior in Airflow.	Apache Airflow 3.3.2, Time Zones: https://airflow.apache.org/docs/apache-airflow/stable/authoring-and-scheduling/timezone.html 9	Version 3.3.2; inspected 2026-10-10	timezone-aware scheduling and DST guidance	Project documentation	Supported for Airflow	Keep, qualify by implementation
Airflow brings a control plane that itself requires production operations.	Apache Airflow 3.3.2, Production Deployment: https://airflow.apache.org/docs/apache-airflow/stable/administration-and-deployment/production-deployment.html 3	Version 3.3.2; inspected 2026-10-10	External DB, multi-node executor, logs, scheduler uptime/health, upgrades	Project documentation	Supported	Keep; essential counterweight to “orchestration = free reliability”
Airflow upgrades may require metadata DB migrations and careful testing.	Apache Airflow, Upgrading Airflow: https://airflow.apache.org/docs/apache-airflow/stable/installation/upgrading.html 14	Stable docs inspected 2026-10-10	migration/backup/testing guidance	Project documentation	Supported	Keep when discussing upkeep, not as argument that Airflow is inherently problematic
Civil time rules change and require maintained zone data rather than hard-coded offsets.	IANA, Time Zones: https://www.iana.org/time-zones 7	tzdb 2026e released 2026-09-29; inspected 2026-10-10	database purpose, ongoing rule updates, latest release	Primary standards/infrastructure source	Supported	Keep
“An AI agent should decide whether the daily report is complete.”	No primary evidence identified that would justify probabilistic AI as the default completion authority for this deterministic workflow	N/A	N/A	Editorial architecture decision	Unresolved as empirical claim; unnecessary technically	Remove as default design. Use bounded AI only for triage/explanation after deterministic state is established.
“Airflow has lower cost than a script once there are N steps.”	No directly applicable primary comparative evidence found	N/A	No controlled same-workflow cost study found	Evidence gap	Unresolved	Remove numeric threshold; use operational-complexity criteria instead
“An orchestrator reduces incident frequency by X%.”	No directly applicable primary evidence found	N/A	No causal comparison found	Evidence gap	Unresolved	Remove unless a future study supports it

All sources in this table were inspected on 2026-10-10.

Contradictions, counterevidence, and unresolved gaps

“Cron is too primitive for reliable business automation”

Too broad.

Google’s first-party account is direct counterevidence: it built and heavily used a robust distributed cron service. The important lesson is not “cron wins,” however; Google’s solution gained reliability by adding replicated durable state, consensus, launch identity, monitoring and partial-failure recovery. 1

systemd also supplies functionality absent from the caricature of cron: persistent catch-up, wall-clock calendar schedules, monotonic schedules and explicit timezone support. 8

Revised claim: Bare scheduling is insufficient when business completion requires durable workflow state. A simple scheduler can still be entirely appropriate if a small coordinator owns that state.

“Use an orchestrator because it retries failures”

Insufficient decision criterion.

A managed scheduler can retry invocation; application code can retry operations; systemd can catch up missed calendar activations; Kubernetes offers deadlines/concurrency handling. 4

The stronger orchestrator benefit is the combined model of tasks, dependency states, retries, historical runs, data intervals and backfill. Airflow’s value is not the existence of a retry loop in isolation. 2

“Airflow makes the workflow reliable”

Qualify heavily.

Airflow externalizes workflow state and supplies recovery mechanisms, but its own production deployment has failure and maintenance surfaces. The project’s documentation calls for scheduler health checks, production metadata storage, logging architecture and careful upgrades. 3

And a successful Airflow DAG is not, by definition, the same as correct business completion. The documented all_done leaf counterexample is unusually strong evidence against that shortcut. 2

Revised claim: Airflow can make workflow state and recovery easier to operate, provided the team also operates Airflow and preserves an explicit business-acceptance contract.

“Use UTC and DST disappears”

Wrong when the business requirement is local civil time.

UTC eliminates ambiguity in stored instants and elapsed calculations. It does not preserve “06:30 Prague local” or “08:00 New York local” across offset changes. Cloud Scheduler’s documentation explicitly distinguishes this trade-off, and Airflow/systemd expose separate scheduling semantics for calendar versus elapsed-time requirements. 10

The correct advice is:

Store/compare instants in UTC; define business civil schedules in an explicit IANA zone when local time is what the business means.

“Weekdays in cron equal business days”

This dossier does not support that assumption. Cron-style weekday rules can express weekdays, but the relevant process also requires organization/jurisdiction-specific holidays, exceptional closures and potentially reporting-period conventions. The business calendar should therefore be separate, explicit and versioned. This is an editorial process-design recommendation rather than a documented universal scheduler limitation.

The Czech-versus-US distinction matters here only at the configuration layer: named zones and business calendars differ. No evidence found suggests a different underlying orchestration decision criterion between the two markets.

“Yesterday's data succeeded downstream, therefore yesterday was intended”

Rejected by the process contract.

Execution success proves that software executed, not that the correct logical data was selected. Airflow’s data intervals are one implementation mechanism for making logical temporal identity explicit, while Google’s cron design makes a similar point about unambiguous launch identity. 2

This is why the final acceptance must inspect period/version metadata, not only task status.

Evidence limitations and source-access gaps

No private production evidence was used. No customer result, internal incident rate, or empirical ROI was available.

The upstream Cronie crontab.5 GitHub page was attempted during research but returned an HTTP 503 through the research fetcher. Consequently, this dossier does not rely on Cronie-specific claims about DST skipped/repeated times. systemd, Kubernetes, Cloud Scheduler and Airflow are used only for their respective documented semantics; none is treated as evidence of universal “cron behavior.”

The canonical freedesktop systemd HTML manual surfaced in search, but the GitHub upstream systemd documentation source was inspected because it was directly accessible. The main branch is inherently moving and should be rechecked before publication.

Airflow documentation was inspected at 3.3.2. Some pages expose the software version but not an independent page-publication date. Those rows are therefore identified by version and inspection date rather than inventing a source date.

IANA 2026e was current on 2026-10-10. Because timezone rules can change in response to political decisions, examples involving future local times should be re-evaluated against the then-current tzdb rather than permanently hard-coded. 7

The executed Python harness used the runtime’s zoneinfo database. Its exact packaged tzdb version was not independently established, so its DST assertions are evidence of the synthetic runtime behavior tested here, not proof that the runtime was specifically using IANA 2026e.

Google SRE’s cron and pipeline chapters are unusually relevant first-party practitioner sources, but Google’s infrastructure and scale are not representative of an ordinary Czech or US SME. Google itself discusses data-center-scale concerns that may not exist in a one-team reporting workflow. 1

Most importantly, no controlled primary comparison was found that assigns a causal operational benefit to moving this exact process from a durable script to Airflow. Any claim such as “Airflow reduces failures by X%” or “pays back after N workflows” remains unsupported.

Practical implications, candidate angles, and freshness triggers

Practitioner decision test

For a team choosing today, I would use the following sequence.

First ask whether the process can be simplified. Remove unnecessary steps, establish one exact source manifest, separate reporting period from execution time, and define business acceptance. Automating an ambiguous process faster is not leverage.

Then implement the smallest state machine that satisfies the actual failure requirements. For this dossier’s workflow, that means the correlation key, manifest validation, durable stage state, duplicate/overlap protection, timeout, replay/backfill and reconciliation described above. Google’s experience with partial cron failures strongly supports making identity and state recovery explicit. 1

Only after that ask how much of this machinery should be owned locally.

I would keep the small coordinator when the pipeline remains linear, one team can understand its state model completely, recovery is infrequent, and its durable ledger is easy to operate.

I would adopt an orchestrator once the coordinator starts acquiring a generic scheduler, graph engine, multiple queues, per-task historical UI, backfill controller, dependency sensors, retry-management UI and operational APIs. At that point the team is no longer avoiding orchestration—it is implementing one.

That is the practical “smell test” I would use instead of a threshold such as “five tasks means Airflow.”

Ownership model

A scheduler owner who is responsible only for “the 06:30 trigger fired” is insufficient for this business process.

The owner needs an observable question with a business answer:

For reporting_period=P and version=V,
was the accepted report available by deadline=D?

A useful operational dashboard should therefore center on period states:

2026-10-05 / export-v7 / ACCEPTED       / 07:42
2026-10-06 / export-v8 / WAITING_LATE   / source absent
2026-10-07 / export-v9 / TRANSFORMED    / report publication retrying

rather than merely:

cron process: ran
dbt process: success
report process: success

This distinction follows the source evidence that workflow/run state and user-visible data correctness are distinct concerns. 2

Optional AI role

For this deterministic workflow, an AI agent should not be the scheduler, lock service, period authority, or final completion authority by default.

A bounded AI component could summarize an alert such as:

Expected export-v12 for 2026-10-09 is 47 minutes late.
Previous five runs arrived between 06:02 and 06:18.
No downstream stages have executed.

or help classify a human-readable provider error. But the state transition to ACCEPTED should remain deterministic and reproducible.

This is an editorial architecture recommendation. No empirical claim is made that adding or excluding AI changes incident rates.

Reusable assets from this dossier

The principal portable asset is the executed test harness:

workflow_orchestration_acceptance_harness.py [original file unavailable]

A reusable implementation package could additionally extract three artifacts directly from this dossier without changing its evidence claims:

Asset	Purpose
Time/period contract template	Forces business_zone, reporting period, local schedule, elapsed timeout, business calendar, deadline and correlation key to be declared.
Dependency state/timeout/recovery table	Makes waiting, partial failure, lateness, cancellation and final acceptance explicit.
Acceptance fixture suite	Lets a script implementation and an orchestrator implementation face the same DST, late-input, wrong-period, duplicate, overlap, restart and backfill cases.

No Airflow DAG, Cloud Scheduler deployment file or systemd unit was executed as part of this dossier, so none is presented as a tested asset.

Candidate distinct article angles

Angle	Core thesis	Evidence strength
A cron job is not a workflow contract	Scheduling a command and proving a business process completed are separate problems.	Strong architecture/documentation support from Google SRE, Airflow and scheduler docs. 1
Tomorrow at 06:30 is not always 24 hours from now	Local calendar schedules, UTC instants and elapsed intervals need distinct contracts.	Strong provider/standards documentation plus executed synthetic fixtures. 7
Your second automation should wait for the right data, not a green light	Correlate by logical period/version and make whole-business completion explicit.	Strong architecture support; exact business contract remains editorial design. 1
When a script grows into an orchestrator—and why that can still be fine	Durable state/locks/reconciliation turn a script into a tiny coordinator; for one bounded workflow this can still beat a general platform.	Evidence supports required mechanisms; crossover recommendation is practitioner interpretation.
Orchestrators move complexity; they do not delete it	Airflow buys run/dependency/backfill operations while introducing its own database, scheduler, executor, logging and upgrade lifecycle.	Directly documented by Airflow. 3
Green is not done	Platform task/DAG status is weaker than business acceptance.	Particularly strong Airflow counterexample plus data-integrity rationale. 2

Freshness triggers

This dossier should be revalidated when any of the following changes:

Timezone database: a new IANA tzdb release, especially one affecting relevant jurisdictions. IANA’s current release at inspection was 2026e. 7

Scheduler implementation/version: Cloud Scheduler delivery/time-zone semantics, Kubernetes CronJob behavior, systemd timer behavior, or whichever concrete scheduler replaces them. The research deliberately does not generalize one scheduler’s guarantees to another. 10

Airflow version: changes to catchup/backfill, scheduling, deadlines, task states, executor architecture, upgrade requirements or DAG-run semantics. This dossier inspected Airflow 3.3.2. 3

Business contract: a new reporting deadline, source readiness expectation, source-versioning mechanism, holiday calendar, reporting period, or owner. Those changes can invalidate the automation design without any software upgrade.

Workflow topology: new upstream/downstream systems, parallel branches, cross-team ownership, substantially more frequent backfills or materially greater concurrency. Those are the conditions most likely to move the recommendation from a small durable coordinator toward a dedicated orchestrator.

Operational pain: repeated incidents where operators cannot determine what ran, what period it belonged to, what is safe to rerun, or what remains incomplete. That is stronger evidence for orchestration than the raw count of scripts.

The evidence therefore supports a deliberately non-dogmatic conclusion: use the simplest implementation that can make the required business state explicit and recoverable. For a truly simple periodic task, that can be a timer. For this bounded multi-stage workflow, it is at least a durable coordinator. Adopt a general orchestrator when the repeated operational value of its state model, dependency handling, backfill and shared operating interface exceeds the control-plane burden it introduces. 1

Portable citation index

[1] Google SRE: Distributed Periodic Scheduling with Cron Service

[2] Dag Runs — Airflow 3.3.2 Documentation

[3] Production Deployment — Airflow 3.3.2 Documentation

[4] About Cloud Scheduler  |  Google Cloud Documentation

[5] Google SRE - Managing Data Processing Pipelines: Challenges

[6] Google SRE - Data Integrity: Principles and Best Practices

[7] Time Zones

[8] systemd/man/systemd.timer.xml at main · systemd/systemd · GitHub

[9] Time Zones — Airflow 3.3.2 Documentation

[10] Cron job format and time zone  |  Cloud Scheduler  |  Google Cloud Documentation

[11] Tasks — Airflow 3.3.2 Documentation

[12] CronJob | Kubernetes

[13] systemd/man/systemd.time.xml at main · systemd/systemd · GitHub

[14] Upgrading Airflow® to a newer version — Airflow 3.3.2 Documentation

Workflow Orchestration Versus Simple Scheduled Scripts

Decision evidence dossier — research snapshot: October 10, 2026

Decision answer and uncertainty

Bottom line

For the bounded daily process studied here — source export → immutable raw preservation → ingestion → dbt/warehouse transformation → business report — I would not adopt a workflow orchestrator merely because the process has multiple steps.

For a small data team, the strongest default is:

First define the business-period and completion contract. Then implement the smallest system that can durably enforce it.

For one daily pipeline, that can credibly be a simple runner plus durable state, locking/idempotency, explicit period/version checks, reconciliation, and a managed/native scheduler. Once those requirements expand into frequent cross-workflow dependencies, waits, backfills, parallel branches, per-task recovery, multiple operators, and incident handover, an orchestrator becomes progressively easier to justify.

The important distinction is therefore not “cron versus Airflow.” It is:

stateless time-triggered execution
versus
stateful business-process execution.

A cron expression or cloud scheduler answers approximately when should something be invoked? It does not by itself prove that the correct source period arrived, the correct version flowed through every stage, the report is current, or the business outcome completed. Google Cloud Scheduler, for example, explicitly provides at-least-once delivery and warns that a scheduled execution can be delivered more than once; Kubernetes similarly describes CronJob scheduling as approximate and says two Jobs or no Job can occur in some circumstances. Both therefore push idempotency into the workload design. 1

An orchestrator such as Airflow does provide materially more lifecycle machinery: task dependencies, per-task state, data intervals, retries, timeouts, catchup/backfill, and persistent workflow metadata. 2 But it does not remove the need for a business completion rule. Airflow’s own documentation gives a revealing counterexample: a DAG can be marked successful even when an intermediate task failed if a successful leaf task uses an all_done trigger rule. 3

That produces the decision rule I would use:

Situation	Preferred starting point	Why
One bounded daily chain, one accountable technical owner, sequential dependencies, occasional replay	Managed/native scheduler + simple stateful runner	Lowest additional control-plane burden while meeting the requirements if state/reconciliation are implemented properly
Same chain, but existing platform already has reliable native job/dependency automation	Native platform automation	Reuse the control plane you already operate; avoid introducing a second scheduler
Frequent late inputs, waits, partial reruns, backfills, fan-out/fan-in, several workflows or operators, incident handover	Workflow orchestrator	Persistent workflow/task state and first-class recovery increasingly replace custom coordination code
Very small volume and low consequence of lateness	Manual checklist/runbook may still win	Automation has upkeep; eliminating or standardizing the problematic step can be more valuable than automating it
Strict/audited completion requirements but only one pipeline	Either stateful runner or orchestrator, evaluated on recovery evidence rather than pipeline count	Criticality can justify orchestration even before scale does
Source can reliably emit a readiness event with period/version	Prefer event/readiness-driven start over blindly fixed-time start	Removes an unnecessary race between “06:30 arrived” and “the correct data is ready”

The last three rows are decision heuristics, not results of comparative trials. I found no controlled public study establishing a universal break-even number of jobs, tasks, incidents, or engineers at which an orchestrator becomes economically superior.

The main uncertainty

The public evidence is asymmetric. Product documentation is strong on what specific implementations are designed to do, but weak on comparative operational outcomes. The empirical data-pipeline literature I found does not demonstrate that introducing an orchestrator reduces incident rates or total cost for a small team’s bounded daily pipeline. One relevant empirical study developed a 41-factor data-pipeline-quality taxonomy and found significant problems around data types, cleaning, ingestion and integration — evidence that scheduling/orchestration is only one part of pipeline reliability, not a general cure for it. 4

Accordingly, this dossier treats:

Documented behavior as evidence of platform capability;
architecture comparisons as reasoned interpretation;
the worked process and economics as explicitly synthetic; and
the supplied tests as firsthand execution only of the synthetic fixture, not of Airflow, Kubernetes, Cloud Scheduler, dbt, a warehouse, or a production source.

Bounded process and time-period contract

The recognizable business process

The reference process is a daily sales/operations report. The source system produces an export for business date (D). The data team must preserve that source, ingest it, transform it in the warehouse using dbt, validate it, publish the resulting report, and declare the period complete by a business deadline.

The key change from a typical “run this every morning” design is that the scheduled time is not the identity of the work. The identity is the business period and source version.

Element	Reference design
Business owner	Consumer of the daily sales/operations report
Technical owner	Data/analytics engineering owner or on-call
Trigger	Daily calendar schedule at 06:30 Europe/Prague, plus manual/reconciliation triggers
Expected work identity	pipeline_id + business_date + source_version
Business date	(D =) scheduled local calendar date minus one calendar day
Source input	Export manifest declaring (D), source version, generation time and checksum plus payload
Raw preservation	Immutable/path-versioned copy keyed by (D), version and checksum
Ingestion	Loads only the preserved input for the declared (D)/version
Transformation	dbt/warehouse processing explicitly scoped to (D)/version
Validation	Technical tests plus explicit period/version/freshness assertions
Publication	Report/snapshot labelled with (D)/version
Business completion	Correct (D)/version accepted by 08:30 Europe/Prague
Failure	Anything that prevents that acceptance, even if every process happened to return exit code 0

dbt’s run_results.json is useful evidence of a completed dbt invocation and records timing/status information for executed nodes, but that artifact describes dbt execution; it does not itself establish that the business report contains the required period/version or met a business deadline. 5 That distinction is central here.

Simplest manual baseline

The minimum reliable baseline is not “five cron entries.” It is an operator following one small, explicit checklist:

The operator identifies (D), verifies that the source manifest says (D), preserves the file and checksum, runs ingestion for (D)/version, runs the warehouse/dbt transformation for the same identity, checks validation results, verifies the published report identifies (D)/version, and records ACCEPTED in a shared ledger.

That baseline is intentionally boring. It separates the process contract from the implementation. If the team cannot unambiguously perform and verify the process manually, adding a workflow engine tends to automate ambiguity rather than resolve it.

Before automation I would therefore challenge the process in this order:

Remove unnecessary handoffs or duplicate exports → standardize one period/version identifier → make source readiness observable → define completion and failure → only then choose the automation technology.

Inline time and period contract

The required time contract should be part of the system specification, not tribal knowledge.

Contract field	Proposed value	Semantics
business_calendar_zone	Europe/Prague	IANA geographical zone, not merely CET or an offset
business_date	explicit local calendar date (D)	Independent run parameter; never reconstructed later from “now”
Reporting interval	([D\ 00{:}00,\ D+1\ 00{:}00)) in Europe/Prague	A calendar-day period, not “24 elapsed hours”
Normal scheduled invocation	06:30 local on (D+1)	Local civil/calendar schedule
Source normal expectation	06:15 local	Synthetic operating assumption
Late-source alert	07:15 local	Synthetic policy; waiting may continue
Business completion deadline	08:30 local	Period must be accepted, not merely started
Hard automated-recovery cutoff	12:00 local	Synthetic policy; beyond it require explicit operator decision
Retries	elapsed duration, e.g. 5 min → 10 min → 20 min	Measure in UTC/monotonic elapsed time; do not use civil-clock arithmetic
Backfill	explicit set/range of business dates	Never implement as repeated now - 24h
Weekend policy	daily, including weekends	Change only through an explicit business-calendar rule
Holiday policy	daily by default	If business-day-only, reference a versioned business calendar
Source revisions	new source_version, never silently overwrite accepted input	Reprocessing must be explicit
Timestamp storage	source/schedule/acceptance UTC instants plus relevant IANA zone and business date	Separates an instant from business-calendar meaning

This distinction matters because calendar schedules and elapsed intervals are different abstractions. Airflow explicitly distinguishes delta-based timetables, which run after an elapsed delta and need not align to hour/day boundaries, from cron/data-interval schedules aligned to cron trigger points. 6 Google Cloud Scheduler likewise says its timezone-based scheduler runs on wall-clock time, warns that daylight-saving transitions can make executions anomalous, and recommends UTC when a very specific cadence is required. 7

Consequently:

“Every day at 06:30 Europe/Prague” and “every 24 hours” are not the same contract.

The IANA timezone database is built around geographical timezone identifiers and civil-time rules; it also explicitly warns that future timezone predictions can become wrong after governments change rules. 8 The practical implication is to store Europe/Prague or America/New_York, not bake today’s UTC offset permanently into future business schedules, and to treat timezone-rule updates as a freshness trigger.

Czech and US deployments do not require different architecture advice on this evidence. The material difference is simply that a US business process might use a zone such as America/New_York while the Czech process uses Europe/Prague; their DST transitions occur under their respective civil-time rules. The same period/version contract is appropriate to both. IANA also cautions that timezone abbreviations can be ambiguous in practice, further supporting geographical zone identifiers for business rules. 8

One should not infer a universal DST policy from the word “cron.” Different systems define edge cases differently. RFC 5545, for example, has specific rules for interpreting repeated and nonexistent local calendar times, while Cloud Scheduler documents its own wall-clock behavior and potential DST anomalies. Those are implementation-specific semantics, not a universal cron guarantee. 9

A particularly simple risk reduction is to avoid scheduling this daily job inside the likely clock-transition window at all. The synthetic design uses 06:30 local, while still testing DST-crossing periods and backfills, because the reporting day itself can contain 23 or 25 elapsed hours.

Same requirements across the alternatives

The fair comparison is to give every approach the same completion requirements. A deliberately weak shell script should not be compared with a fully engineered orchestrator and then declared inherently unreliable. Conversely, once the script gains durable state, locking, retries, reconciliation and history, that engineering effort must count against its apparent simplicity.

Capability comparison

Requirement	Host-local cron-style scheduled script	Managed/native scheduler + runner	Representative orchestrator: Airflow 3.3.2
Invoke at a schedule	Scheduler does this	First-class scheduler capability	First-class timetable/scheduler capability
Explicit timezone	Implementation-specific; must inspect actual scheduler	Cloud Scheduler supports timezone selection and defaults to UTC	Cron timetables accept timezone; other timetable types support elapsed-delta semantics
Dependency graph	Code/runbook	Usually application code unless native product adds workflow semantics	Explicit DAG dependencies
Same-period correlation	Must implement	Must implement	Data intervals help correlate task instances, but source version remains application logic
Durable business state	Custom DB/ledger	Custom DB/ledger	Workflow/task state stored in metadata DB; business acceptance still custom
Duplicate handling	Custom idempotency	Required: Cloud Scheduler can deliver a scheduled invocation more than once	Side-effect idempotency still required even with task state/retries
Overlap control	Lock/lease	Lock/lease plus scheduler-specific facilities	Concurrency/task controls plus application-level side-effect protection
Step retry	Shell/application logic	Application logic plus trigger-level retry where supported	Task retry is first class
Wait for late data	Polling/application state	Polling/application state	Sensors/deferred patterns and timeouts
Timeout	Application logic	Scheduler/request timeout plus application business timeout	Task execution_timeout; sensors have overall timeout semantics
Partial recovery	State-machine logic	State-machine logic	Clear/re-run selected tasks; task history/state available
Backfill	Loop over explicit dates	Explicit replay loop	First-class date-range backfill
Missed-run reconciliation	Startup/period scanner	Period scanner recommended	Catchup or backfill, but catchup is not on by default
Observable whole-process state	Custom dashboard/SQL/logs	Custom ledger + provider logs	UI/API plus DAG/task states, but business acceptance needs explicit design
Control-plane burden	OS/host + runtime + state store	Application/state store; scheduler operated by provider	Scheduler, DAG processor, API server, DAG bundle and metadata DB at minimum
Platform upgrades	Runtime/OS/dependencies	Application dependencies; provider manages scheduler service	Airflow upgrades can include metadata DB migrations
Handover to another operator	Depends heavily on runbook/ledger quality	Better if state ledger is explicit	Usually easier because task/run history and workflow UI are first-class
Exit/migration	Simple executable/state schema potentially portable	Scheduler-specific trigger configuration plus portable runner	DAG/platform semantics can create greater migration surface

Cloud Scheduler is a useful representative of the middle category. It sends a scheduled unit of work to a target, provides configurable retry behavior, explicitly promises at-least-once delivery, and exposes the original schedule time for deduplication. 10 That is significantly more reliable as a trigger service than “hope one laptop is awake,” while still leaving cross-step business state with the application.

Kubernetes CronJob illustrates why “cron-format scheduler” must not be treated as a universal reliability specification. Kubernetes supports an explicit .spec.timeZone, delayed-start deadlines and concurrency policies, but its documentation calls Job creation approximate, says duplication or absence can occur, and recommends idempotent Jobs. 11 It can also stop catching up after more than 100 missed schedules in the documented circumstances. 11

Airflow provides a different abstraction. Tasks in one DAG run share a data interval, upstream success normally gates downstream execution, and task instances carry explicit lifecycle states such as scheduled, queued, running, success, failed, upstream-failed and up-for-retry. 2 Its scheduler monitors dependencies and triggers eligible task instances. 12 For a pipeline where operators frequently need to answer “which step for which period failed?”, this is genuine leverage rather than cosmetic UI.

Airflow’s catchup/backfill machinery is also materially different from a raw timer. Catchup can generate a run for each missed data interval, while backfill can explicitly process a historical date range with reprocessing and concurrency options. But catchup defaults to false, and Airflow cautions that code which uses “now” rather than the interval may not be written safely for catchup. 3 An orchestrator therefore makes correct period-oriented execution easier; it does not make badly periodized application code correct automatically.

The complexity the orchestrator introduces

For the same tiny pipeline, Airflow is not “just cron with arrows.” A minimal Airflow 3.3.2 installation has a scheduler/executor, DAG processor, DAG bundle, API server and metadata database. 13 Its production documentation says the default SQLite setup is for testing and warns that production deployment needs an external supported database such as PostgreSQL or MySQL. 14

Upgrades can require schema migrations, and Airflow recommends backing up the metadata database because a failed migration can leave a half-migrated state. 15 Managed Airflow products can shift some of that work to a provider, but they do not remove DAG testing, runtime compatibility, workflow ownership, source/warehouse permissions or incident responsibility.

This is the strongest counterweight to an automatic “use an orchestrator” recommendation: the orchestration control plane is another production system whose health and lifecycle become part of the reporting pipeline.

A key design insight: a good script starts resembling a small orchestrator

To meet the stated requirements, the simple implementation needs at least:

durable period ledger
+ step states
+ idempotency keys
+ lock/lease
+ exact source-version checks
+ retries classified by error
+ deadline/timeout handling
+ logs/metrics
+ reconciliation loop
+ backfill command
+ operator runbook

That does not mean “therefore Airflow.” It means the decision should be made on which machinery the team prefers to own.

For one stable sequential workflow, a few hundred lines of explicit state-machine code plus a relational table can be easier to reason about than an orchestration platform. For dozens of workflows, repeatedly rebuilding those same primitives becomes questionable. The evidence does not supply a universal numerical boundary between those cases.

Failure, recovery and acceptance

Dependency state, timeout and recovery contract

The following state model is proposed architecture, not observed production behavior. Times are synthetic policy inputs.

State	Required correlation	Timeout / trigger	Recovery or next transition
DUE	pipeline_id, D	06:30 scheduled trigger or reconciliation finds missing period	Look for source manifest
WAITING_SOURCE	exact (D), expected source	Alert 07:15; keep checking until hard cutoff 12:00	On source arrival, checksum and preserve raw; no transformation on substitute/stale data
RAW_PRESERVED	(D), source_version, checksum	No short business timeout; must remain recoverable	Resume ingestion from preserved object
INGESTING	same (D)/version; lease + attempt ID	Synthetic 15-minute lease	Retry safely after lease expiry; do not duplicate accepted side effects
INGESTED	same (D)/version recorded in staging metadata	Downstream immediately eligible	Transform only declared period/version
TRANSFORMING	(D)/version passed explicitly	Bounded task timeout	Retry transient failure or move to operator-required state
TRANSFORMED	transformation output declares (D)/version	Immediate validation	Run data/period/freshness tests
VALIDATED	required tests passed	Immediate publication	Publish report version
REPORT_PUBLISHED	report metadata = (D)/version	Acceptance deadline 08:30	Final acceptance gate
ACCEPTED	all contract predicates true	Terminal	No implicit replacement by later source revision
RETRYABLE_FAILED	attempt/error class retained	Exponential elapsed-time backoff	Resume failed step, not entire workflow unless required
BLOCKED_AUTH	failing resource and credential owner identified	Do not blindly retry forever	Rotate/restore permission, then replay from durable state
TIMED_OUT	state/attempt retained	Business or technical timeout exceeded	Reconcile external side effects before retry
RECOVERY_NEEDED	evidence of wrong/stale period, inconsistent output, or uncertain side effect	Immediate operator attention	Determine authoritative state, compensate or replay
SUPERSEDED	old and new source versions both retained	Explicit revision event	New controlled run; never silently relabel old output

Airflow can represent substantial portions of this mechanically: dependencies, task-instance states, retries, execution timeouts and waiting sensors are documented capabilities. 2 But source_version, business acceptance, source-revision policy and reconciliation with external side effects remain domain concerns.

Worked failure: source arrives after the fixed schedule

At 06:30 Europe/Prague, the scheduler triggers the run for business date 2026-10-09. The source export has not yet arrived.

A weak implementation executes:

SELECT latest available sales
→ latest available happens to be 2026-10-08
→ dbt succeeds
→ report publish succeeds
→ cron exits 0

Technically, the automation “worked.” Business-wise, it failed.

The reference design instead executes:

expected_business_date = 2026-10-09
source_manifest(2026-10-09) = absent

state = WAITING_SOURCE
report = not publishable
business_completion = false

At 06:52 the manifest for 2026-10-09 / v1 appears:

preserve raw payload + SHA-256
→ ingest 2026-10-09/v1
→ transform 2026-10-09/v1
→ validate period/version
→ publish report 2026-10-09/v1
→ write ACCEPTED

The important control is not the retry. It is refusing to replace the missing expected period with whatever data happens to exist.

Worked failure: downstream succeeds on yesterday's data

Suppose ingestion correctly processes (D), but a transformation accidentally queries a warehouse table still containing (D-1). The SQL succeeds and dbt reports the node as successful.

The completion predicate must therefore contain something like:

\text{accepted}(D,v)=
S \land R \land I \land T \land V \land P \land M

where:

• (S) = source manifest identifies (D,v)
• (R) = raw source (D,v) is preserved and checksummed
• (I) = ingestion finished for (D,v)
• (T) = transformation consumed the declared (D,v)
• (V) = required validations passed
• (P) = report for (D,v) was published
• (M) = acceptance occurred within the business deadline

A task/process exit code is only one input to those predicates.

This also challenges the idea that an orchestrator’s green workflow indicator is automatically the business truth. Airflow explicitly derives DAG-run status from terminal leaf states and warns that certain trigger-rule designs can yield DAG success despite a failure in the middle. 3 The reference DAG should therefore end in an explicit acceptance task whose own inputs verify the business predicates, rather than treating generic DAG completion as sufficient evidence.

Worked failure: scheduler/host interruption

Assume a host-local scheduler is unavailable when 06:30 passes.

The robust script design does not depend on assumptions about whether that particular cron implementation catches up. At process startup, and periodically thereafter, it performs reconciliation:

expected periods through current business deadline
MINUS
periods whose durable status = ACCEPTED
=
periods requiring inspection/recovery

If 2026-10-09 is missing, the runner creates/reclaims the durable work item and continues from its last confirmed state.

Airflow has native catchup/backfill concepts, but catchup is disabled by default, so the operator must make the intended recovery semantics explicit. 3 Kubernetes has its own delayed-start and missed-schedule rules. 11 This variation reinforces the broader point: cron syntax is not a recovery contract.

Worked failure: replay crosses daylight-saving time

For Europe/Prague, define the business period as local-calendar midnight to next local-calendar midnight. The synthetic fixture evaluates:

2026-03-28 -> 24 elapsed hours
2026-03-29 -> 23 elapsed hours
2026-03-30 -> 24 elapsed hours

and the autumn transition day as:

2026-10-25 -> 25 elapsed hours

A backfill covering these days therefore creates one business run per calendar date, rather than chopping history into fixed 24-hour UTC windows.

The fixture also classifies Europe/Prague 2026-03-29 02:30 as nonexistent and Europe/Prague 2026-10-25 02:30 as ambiguous. A corresponding US test classifies America/New_York 2026-03-08 02:30 as nonexistent.

These are actually executed synthetic tests, not provider tests. They ran under Python 3.13.5 using the runtime’s IANA tzdb 2025b. Eleven tests passed. They do not demonstrate how any external scheduler behaves.

The portable asset contains the code, fixtures, proposed SQL state schema, test cases and captured test run:

Download the synthetic period/recovery test assets [original file unavailable]

The package explicitly labels unperformed cases such as real credential expiry, warehouse outages, scheduler control-plane outages and source-version revisions.

Acceptance cases

Case	Expected invariant	Script/native implementation	Orchestrator implementation
Source arrives late	Do not use earlier period	Reconciliation/waiting state	Sensor/wait task plus exact-period check
Duplicate trigger	One logical side effect	Unique idempotency key / durable state	Same; task state alone does not make external API writes idempotent
Previous attempt died after raw save	Do not download/recreate input unnecessarily	Resume from RAW_PRESERVED	Retry/clear downstream task after verifying prior side effect
Transformation uses stale date	Reject apparently successful run	Acceptance predicate fails	Explicit terminal validator fails
Permission expires	Do not retry endlessly	Classify as operator-required	Configure retry policy/terminal failure; operator repairs credential
Host/scheduler unavailable	Recover missing business period	Reconciliation scanner	Catchup/backfill/retrigger under explicit policy
Backfill crosses DST	One run per declared business date	Iterate dates, derive UTC boundaries separately	Use data intervals/backfill designed around explicit periods
Source releases revised v2 after v1 accepted	Never mutate historical meaning silently	Create controlled reprocess/supersession	New run/reprocessing policy; source version remains domain metadata
Report task times out after remote publish	Determine whether publication actually happened before retry	Query remote/report state, then reconcile	Same requirement; orchestrator cannot infer an external side effect it did not observe

That last row is one of the most important lifecycle cases: timeout does not imply “nothing happened.” Recovery must first reconcile the external system before replaying a non-idempotent action.

An optional AI system may help classify logs, summarize an incident, or propose a recovery action. It should not be the authority deciding that period (D) is complete unless the completion condition itself genuinely requires probabilistic judgment. For this pipeline, period/version/deadline acceptance is deterministic and should remain so.

Practical decision, pilot economics and exit criteria

What I would approve for the small-team case

I would first approve a bounded pilot of managed/native scheduling plus a stateful runner, not a new self-managed orchestrator, provided the team can demonstrate all of the following:

Approval evidence	Minimum bar
Period contract	Explicit business_date, timezone, source version and deadline
Durable state	Survives process/host restart
Idempotency	Duplicate invocation demonstrably causes no harmful duplicate effect
Lock/overlap control	Two invocations for the same (D)/version cannot corrupt results
Late source	Runner waits/fails visibly; cannot silently use stale period
Partial recovery	Restart resumes from known durable step
Backfill	Explicit --business-date or bounded date-range replay
Reconciliation	Can detect an expected-but-unaccepted period independently of the scheduler
Permissions	Service identities and credential owners documented
Observability	Owner can answer “what period/version is waiting/failed/accepted?” without SSH archaeology
Handover	Another engineer can recover the pipeline using the runbook
Exit path	Runner logic not tightly coupled to the scheduler so it can later become an orchestrator task

This is not an argument for “DIY forever.” It is deliberately an architecture that can migrate cleanly:

today:
managed scheduler
    ↓
stateful runner(D)

later:
Airflow/other orchestrator task
    ↓
same runner(D)

The scheduler should supply the trigger, while the executable owns the business-period logic. That separation lowers both migration and rollback risk.

When I would skip the pilot and choose orchestration now

I would lean directly toward an orchestrator where several of these are already true:

The pipeline routinely waits on multiple upstreams; independent branches converge; source arrival is variable; operators frequently replay individual stages; historical backfills are normal rather than exceptional; several people share incidents; task-level state needs to survive handovers; there are many pipelines implementing the same home-grown retry/state framework; or the organization already has an orchestrator and competent owners, making its marginal operational burden low.

Airflow directly supports dependencies, stateful task instances, timeouts and date-range backfills, so these are not speculative benefits of the orchestration category, although competing orchestrators must be assessed separately. 2

Conversely, I would defer orchestration when the dominant problem is still that nobody can define which source file constitutes Tuesday’s report. An orchestrator cannot compensate for an undefined period contract.

Transparent synthetic economics

No public source located provides defensible universal ROI inputs for this exact decision, so the useful model is a break-even equation, not a fake business case.

Let:

B = \text{extra orchestrator implementation hours}

A = \text{amortization period in years}

O = \text{extra annual orchestration-platform operating hours}

C = \text{extra annual cash cost converted to equivalent team hours}

S = \text{average engineer hours saved per recovery/backfill event}

Then the annual break-even event count is:

N_{\text{break-even}} =
\frac{B/A + O + C}{S}

A deliberately synthetic illustration:

• incremental orchestration implementation effort (B=40) hours
• amortization (A=2) years
• additional platform upkeep (O=36) hours/year
• cash subscription/infrastructure delta omitted, (C=0)
• operator time saved (S=1.5) hours per incident/backfill

Then:

N =
\frac{40/2+36}{1.5}
=
37.3\text{ events/year}

or roughly 3.1 recovery/backfill events per month.

That is not a forecast or benchmark. Every numerical input is hypothetical. Its purpose is to make the approval question testable: instrument the pilot and replace (B,O,C,S) with the team’s observed values.

It also reveals an often-missed trade-off. If the company already operates Airflow well, (B) and (O) can be close to marginal rather than greenfield costs, strongly favoring orchestration. If nobody currently owns Airflow, those terms can dominate.

Rollback and exit criteria

The simple-runner pilot should migrate to an orchestrator when its custom coordination layer starts becoming a product of its own: numerous state transitions, dependency polling, increasingly sophisticated rerun UI, multiple pipelines duplicating the same code, or sustained operator effort that can credibly be removed by the platform.

The orchestrator should itself be reconsidered when control-plane operations, upgrades and incidents exceed the coordination burden it replaces. Airflow’s required components and metadata database, plus documented migration requirements, make this a real rather than theoretical cost. 13

The rollback-friendly design is to keep ingestion/transformation/publication logic callable using explicit parameters:

pipeline run --business-date 2026-10-09 --source-version v1

rather than embedding all business logic inside scheduler/orchestrator callbacks.

Claim-to-source ledger, contradictions and unresolved gaps

Primary-source ledger

Claim / decision use	Primary source and exact scope	Direct URL / DOI	Source date/version	Inspected	Evidence type	Assessment / editorial treatment
Cloud Scheduler is at-least-once and can execute one scheduled occurrence multiple times; target should tolerate duplicates	About Cloud Scheduler, “at least once” and request deduplication sections	https://cloud.google.com/scheduler/docs/overview	Last updated 2026-10-07	2026-10-10	Provider documentation	Supported. Keep. Applies to Google Cloud Scheduler specifically, not all schedulers. 1
Cloud Scheduler retries unacknowledged failures with configurable exponential backoff; retries can overlap/skip next scheduled execution under documented settings	Retry jobs, retry settings	https://cloud.google.com/scheduler/docs/configuring/retry-jobs	Last updated 2026-10-07	2026-10-10	Provider documentation	Supported. Qualify by provider/configuration. 10
Local wall-clock scheduling and UTC/elapsed cadence are different; Cloud Scheduler warns of DST anomalies	Cron job format and time zone, “Time zone”	https://cloud.google.com/scheduler/docs/configuring/cron-job-schedules	Last updated 2026-10-07	2026-10-10	Provider documentation	Supported. Keep with provider qualification. Strong evidence for article claim about defining which business time matters. 7
Kubernetes CronJob execution is approximate; duplicate or absent Jobs are possible; Jobs should be idempotent	CronJob, “Job creation”	https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/	Current Kubernetes docs; feature page states CronJob stable since v1.21	2026-10-10	Provider/project documentation	Supported. Keep. Never generalize as all cron implementations. 11
Kubernetes supports named timezone, delayed-start deadline and overlap policies	CronJob, “Time zones”, “Deadline for delayed Job start”, “Concurrency policy”	https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/	Timezone feature stable since v1.27	2026-10-10	Provider/project documentation	Supported. Keep as representative scheduler behavior. 11
Airflow represents dependencies and persistent task-instance lifecycle states	Tasks, “Relationships” and “Task Instances”	https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/tasks.html	Airflow 3.3.2	2026-10-10	Project documentation	Supported. Keep. Representative orchestrator capability, not universal. 2
Airflow provides data intervals; DAG success is not necessarily equivalent to every intermediate task succeeding	Dag Runs, “Dag Run Status” and “Data Interval”	https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/dag-run.html	Airflow 3.3.2	2026-10-10	Project documentation	Supported. Important qualification. Justifies explicit business acceptance state. 3
Airflow catchup can instantiate missed intervals; default catchup is false; explicit backfill supports historical ranges	Dag Runs, “Catchup” and “Backfill”	https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/dag-run.html	Airflow 3.3.2	2026-10-10	Project documentation	Supported. Keep. Corrects simplistic “orchestrator automatically catches everything up” claim. 3
Airflow supports task execution timeouts and sensor-wide timeout behavior	Tasks, “Timeouts”	https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/tasks.html	Airflow 3.3.2	2026-10-10	Project documentation	Supported. Keep. Application-level business deadlines remain separate. 2
Cron/calendar and elapsed-delta timetables are separate schedule models	Timetables, DeltaTriggerTimetable, CronTriggerTimetable, DeltaDataIntervalTimetable, CronDataIntervalTimetable	https://airflow.apache.org/docs/apache-airflow/stable/authoring-and-scheduling/timetable.html	Airflow 3.3.2	2026-10-10	Project documentation	Supported. Keep. Good concrete demonstration that “daily” needs semantic definition. 6
Airflow itself has a nontrivial control plane	Architecture Overview, required components	https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/overview.html	Airflow 3.3.2	2026-10-10	Project documentation	Supported. Keep as counterevidence to automatic orchestration adoption. 13
Production Airflow needs more than default SQLite; upgrades can involve DB migration and backup/recovery considerations	Production Deployment and Upgrading Airflow	https://airflow.apache.org/docs/apache-airflow/stable/administration-and-deployment/production-deployment.html; https://airflow.apache.org/docs/apache-airflow/stable/installation/upgrading.html	Airflow 3.3.2	2026-10-10	Project documentation	Supported. Keep. Evidence of lifecycle upkeep, not proof that Airflow is uneconomic. 15
IANA geographical zones model civil-time rules; future conversions can become wrong after government rule changes	Theory and pragmatics of the tz code and data, “Scope” and “Accuracy”	https://data.iana.org/time-zones/tzdb/theory.html	Current tzdb theory page	2026-10-10	Standards/data-project documentation	Supported. Keep. Drives named-zone and freshness policy. 8
Repeated/nonexistent local-time treatment is implementation/standard specific rather than inherent to “cron”	RFC 5545, DATE-TIME with TZID	https://www.rfc-editor.org/rfc/rfc5545.html	September 2009	2026-10-10	Internet standard	Supported as counterexample. Qualify. RFC 5545 describes iCalendar semantics, not cron scheduler semantics. 9
dbt run_results.json records status/timing for executed nodes of completed invocations	Run results JSON file	https://docs.getdbt.com/reference/artifacts/run-results-json	Last updated 2026-09-13	2026-10-10	Provider/project documentation	Supported. Keep but rewrite business claim: dbt success is evidence for transformation execution, not full report acceptance. 5
Pipeline-quality problems extend beyond orchestration/scheduling	Foidl et al., abstract: taxonomy plus GitHub/Stack Overflow mining; incorrect data types, cleaning, ingestion/integration findings	https://arxiv.org/abs/2309.07067; journal DOI 10.1016/j.jss.2023.111855	arXiv v1 2023-09-13; Journal of Systems & Software publication associated with DOI	2026-10-10	Empirical research / primary preprint	Supported but limited. Keep as counterevidence. It is not a cron-vs-orchestrator experiment and cannot establish orchestration effects. 4

Requested draft-claim audit

Draft target	Status	Evidence judgment	Recommended treatment
“Automatizace běží v jiném čase, než čekáte. Který čas má pro firmu platit?”	Supported, but too vague as written	Cloud Scheduler directly documents wall-clock timezone scheduling and DST anomalies; Airflow explicitly distinguishes delta and cron/calendar semantics; IANA makes future civil-time rules mutable. 7	Rewrite: “A schedule is only unambiguous after you decide whether the business means 06:30 Europe/Prague, every 24 elapsed hours, or a UTC instant — and define what happens around DST and business-calendar exceptions.”
“Jedna automatizace čeká na druhou. Kdo hlídá, že celý postup doběhl?”	Supported, with an important qualification	Airflow can explicitly model dependencies and task state, but even orchestrator-level DAG success can misrepresent business completion under certain trigger-rule structures. 2	Rewrite: “When one step waits for another, correlate both to the same business period/version and define a terminal acceptance condition. A green task — or even a green workflow under the wrong rule — is not automatically proof the business process completed.”

Contradictions and counterevidence

There is no contradiction in the sources about the fundamental distinction between schedule time and workflow state. There is a significant contradiction to simplistic recommendations.

“Cron is unreliable; orchestrators are reliable.” Unsupported as a categorical claim. Kubernetes CronJob and Cloud Scheduler document duplicate/retry/missed-execution nuances, but an engineered simple runner can compensate through idempotency and reconciliation. Meanwhile Airflow has its own scheduler, metadata database, deployment requirements and upgrade failure modes. 11

“Managed scheduler means exactly once.” Contradicted for Google Cloud Scheduler, which explicitly says at-least-once delivery and possible multiple deliveries. 1

“An orchestrator means missed dates are automatically backfilled.” Contradicted for default Airflow behavior: scheduler catchup is false by default, though explicit catchup and backfill are available. 3

“Workflow success means the intended report is correct.” Contradicted as a general inference. Airflow warns of DAG-success edge cases based on leaf-node trigger rules; dbt’s run artifact reports execution status, not the independently defined business acceptance contract. 3

“DST can be solved once by converting the schedule to UTC.” Conditional at best. UTC removes local repeated/skipped clock times for the scheduler, but if the business requirement remains “06:30 Prague time,” its UTC instant can change as civil-time offsets change. IANA also warns future rules may be changed by governments. 7

“An orchestrator addresses most data-pipeline reliability failures.” Not established. The empirical pipeline-quality research found substantial issues in data types, cleaning, ingestion and integration; it did not demonstrate causal benefits from orchestration. 4

Unresolved evidence gaps and inaccessible sources

I did not find an original controlled study comparing, for this exact bounded workload, the incident rate, mean recovery time, total engineering effort or cost of a durable scheduled script against an orchestrator. Claims about universal ROI or a magic “number of jobs” threshold should therefore be removed rather than filled with anecdote.

The Journal of Systems & Software publisher page for Foidl et al. was inaccessible during research; the authors’ accessible arXiv primary preprint was used instead. The publisher DOI is retained in the ledger so the substitution is explicit rather than silent.

The Open Group’s current POSIX crontab page returned access restrictions during inspection. I therefore did not use it to claim specific Unix cron catch-up, DST or missed-run guarantees.

The freedesktop.org systemd timer manual pages likewise returned access restrictions during inspection. Consequently, systemd-specific persistence/catch-up semantics were not used as evidence. The dossier deliberately says a host-local design must define its own recovery contract rather than assuming a particular local timer’s behavior.

No real Google Cloud Scheduler, Kubernetes, Airflow, dbt, warehouse or source-system experiment was executed. Provider behavior in this dossier is documented behavior, not firsthand validation.

The synthetic tests used the container’s tzdb 2025b, not necessarily the most recent tzdb release available on October 10, 2026. The fixture therefore demonstrates the mechanics of the proposed contract under that installed rule set; it should not be represented as an independent validation of the latest 2026 timezone database.

Candidate article angles, reusable assets and freshness triggers

The strongest reusable article angle is not “Airflow versus cron.” It is:

“Your scheduler is not your business process.”
A timer tells code to start. The business cares whether the right period/version was accepted by the deadline. The worked stale-data failure gives this angle a concrete, non-vendor-specific backbone.

A second distinct angle is:

“Every day is not always 24 hours.”
Use the local-calendar versus elapsed-time distinction to explain why 06:30 Europe/Prague, every 24 hours, and 06:30 UTC are three different requirements. Cloud Scheduler’s documented wall-clock/DST behavior, Airflow’s delta-versus-cron timetables and IANA’s civil-time model provide unusually clean primary evidence. 7

A third is:

“A simple script stops being simple when reliability matters — but that still doesn’t automatically mean Airflow.”
Walk through the exact additions: durable state, lock, idempotency, retry classification, reconciliation and backfill. The decision becomes whether those few primitives are cheaper to own directly or whether the team is recreating an orchestration platform.

A fourth is:

“Green does not mean done.”
Use the stale-period example plus Airflow’s own DAG-run status caveat and dbt’s execution artifact to show the difference between technical completion and business acceptance. 3

A fifth is:

“Fix the workflow before automating it.”
The sequence would be remove → standardize → identify period/version → define exceptions → automate. This is an editorial/process-design argument rather than an empirical claim and should be labeled accordingly.

A sixth, aimed at decision-makers, is:

“When should a small data team actually buy orchestration?”
Use a capability threshold rather than a job-count threshold: frequent waits, backfills, branching, shared operational ownership and incident handover are the signals. The dossier deliberately does not invent a numerical industry benchmark where none was found.

Reusable assets

The generated package is portable and contains:

period_contract.py — calendar-day boundaries and DST classification;
synthetic_pipeline.py — synthetic period/version state machine and idempotency model;
state_schema.sql — proposed durable state and attempt tables;
fixtures.json — the complete worked time/period contract;
acceptance_cases.csv — proposed cases with executed/unexecuted labels;
test_dossier.py — eleven actually executed standard-library tests;
TEST_RUN.txt — runtime, tzdb version and captured test result; and
README.md — scope and explicit non-claims.

Download the complete portable asset [original file unavailable]

The test result was 11/11 passing under Python 3.13.5 and tzdb 2025b. This is firsthand execution only of the synthetic model. It is not a benchmark, production result, vendor test or customer outcome.

Freshness triggers

This dossier should be rechecked when any of the following changes:

Trigger	What to revalidate
IANA tzdb release or Czech/US time-law change	Future local schedules, DST acceptance cases and UTC projections
Cloud Scheduler behavior/docs change	Delivery guarantee, retry limits, timezone/DST semantics and deduplication identifiers
Kubernetes upgrade	CronJob timezone, missed-run, concurrency and scheduling guarantees
Airflow upgrade	Task/DAG states, timetable semantics, catchup/backfill defaults, architecture and migration requirements
dbt major/version-track change	Artifacts, testing/freshness semantics and retry behavior
Source SLA/versioning changes	Waiting timeout, source-readiness contract and deadline feasibility
Business deadline/calendar changes	Business date, weekend/holiday treatment and acceptance deadline
Pipeline gets a second upstream or fan-out branch	Reconsider orchestrator leverage
Manual recovery/backfill frequency rises materially	Replace the synthetic break-even variables with observed incident data
Another team assumes ownership	Test whether the custom runner’s state/runbook remain operable without original author knowledge
Existing company orchestration platform becomes available	Recalculate marginal orchestration cost; greenfield Airflow burden may cease to be relevant

The durable recommendation is therefore narrower than “use cron” or “use orchestration”: make business time, period identity, completion and recovery explicit; then choose the least complex control plane that demonstrably enforces that contract. For the single bounded daily workflow here, a managed trigger plus a durable, reconciling runner is a defensible first choice. An orchestrator earns its additional surface area when workflow-state management becomes recurring operational work rather than an occasional edge case.

Portable citation index

[1] About Cloud Scheduler  |  Google Cloud Documentation

[2] Tasks — Airflow 3.3.2 Documentation

[3] Dag Runs — Airflow 3.3.2 Documentation

[4] [2309.07067] Data Pipeline Quality: Influencing Factors, Root Causes of Data-related Issues, and Processing Problem Areas for Developers

[5] Run results JSON file | dbt Developer Hub

[6] Timetables — Airflow 3.3.2 Documentation

[7] Cron job format and time zone  |  Cloud Scheduler  |  Google Cloud Documentation

[8] Theory and pragmatics of the tz code and data

[9] www.rfc-editor.org

[10] Retry jobs  |  Cloud Scheduler  |  Google Cloud Documentation

[11] CronJob | Kubernetes

[12] Scheduler — Airflow 3.3.2 Documentation

[13] Architecture Overview — Airflow 3.3.2 Documentation

[14] Production Deployment — Airflow 3.3.2 Documentation

[15] Upgrading Airflow® to a newer version — Airflow 3.3.2 Documentation