Pipelines & automation

Config-driven, scheduled, observable workflows that run without you.

Three processing stages with the configuration, logging and alerting that make them a pipeline. the stages are the easy part; the ring around them is the pipelineconfig.yaml — what to run, and over whatextracttransformloada log, per stagean alert, on failureSwap any stage and nothing else changes — that is what the ring is buying

A pipeline is a batch job with its decisions pulled out. The stages are ordinary functions; what makes it a pipeline is the configuration above them, the logging and the alerting below, and the fact that you can swap one stage without touching anything else.

The value shows up on the days it fails. A named stage in an exception message tells you where; a per-stage log tells you what it was doing; an alert tells you at all. Without those, a scheduled job that has not run for three weeks looks exactly like a scheduled job that has.

Below: the concepts cover what belongs in config and what belongs in code; the how-to guides build the runner, the scheduling, the retries and the reporting; and the fixes are the failures peculiar to work that runs unattended — cron with no environment, a job that never started, a retry that made things worse.

Learning paths run through this topic too — see the end of this page.

🧭 Start with the concepts

The ideas the how-to guides below assume you already have.

Show every concept in this topic

⚙️ Then do the task

Step-by-step walkthroughs with code you can copy and adapt.

Show every how-to guide in this topic

🔧 When it breaks

The errors this topic produces, with the cause explained rather than just the command.

Show every fix in this topic

Related topics

Subjects that keep coming up alongside this one, most overlap first.

Keep browsing

Pipelines & automation sits in Production. Every topic on the site is listed on the topics index.