Schedulers
cron & systemd timers — planned
The scheduler with no database. Will read crontabs, timer units and journal history. This integration is planned: documented here as reference, not connectable from the admin today.
Plenty of production ETL is a shell script in a crontab. It has no metadata database, no run history beyond whatever the script itself logged, and no notion of success or failure that anything else can observe.
systemd timers are a considerable improvement — the journal records start, exit status and output for every invocation — and they are still frequently overlooked, because nobody thinks of a timer unit as part of the data platform.
cron & systemd timers today
There is no Linux agent today. If the script a crontab runs is in a connected GitHub repository, discovery reads it, and a schedule declared in code is recognised as a pipeline trigger. Logs shipped to Google Cloud Logging can be read through a named log source; other logs can be attached to the incident as files.
The sources that ship today are GitHub, Google Cloud Logging, Jira Cloud and the optional Windows agent. Everything below this point describes the planned cron & systemd timers integration: what it is designed to read, and why.
What Decim will read from cron & systemd timers
The intended read-only surface for this integration. It is reference material for the roadmap — and useful on its own, because these are the views and APIs worth knowing during an incident whether or not any tool reads them for you.
| What | From | Why it matters |
|---|---|---|
| User crontabs | /var/spool/cron/crontabs/* | Per-user scheduled commands |
| System crontabs | /etc/crontab, /etc/cron.d/* | System-wide entries, with a user field |
| Periodic directories | /etc/cron.{hourly,daily,weekly} | Scripts run by run-parts |
| Timer units | systemctl list-timers --all | Next and last elapse per timer |
| Service units | systemctl cat <unit> | The command, its user, and its environment |
| Run history | journalctl -u <unit> | Start, exit status and captured output |
| Exit status | systemctl show -p ExecMainStatus | Last exit code for a service |
Permissions it is designed around
Written out in full, because "read-only access" is not a specification. These are the grants the planned integration is designed around and may change before it ships. Nothing below grants the ability to write, and row access would be requested only on the specific tables you name. You do not need to create any of this today.
# Planned Linux agent. Read-only, running as its own unprivileged user.
useradd --system --shell /usr/sbin/nologin decim-agent
# Journal access without root: membership of systemd-journal is enough
# to read unit logs.
usermod -aG systemd-journal decim-agent
# Crontabs are root-owned and mode 600. Grant read via ACL rather than
# widening the mode, so the change is explicit and auditable.
setfacl -m u:decim-agent:r /etc/crontab
setfacl -Rm u:decim-agent:r /etc/cron.d
# Application log directories, read-only.
setfacl -Rm u:decim-agent:rX /var/log/etlWhat it would build
What this source would contribute to the pipeline topology and to the evidence available during an investigation:
- Scheduled work and its cadence — the control layer for a stall with a clock
- The command line actually being run, including its arguments
- Run history and exit status, where systemd is used
- Which user and environment a job executes under
Today, topology is built from code in GitHub, and each connection is marked direct or inferred. The design direction for sources like this one is a provenance model: a step found in a definition is declared, a step seen running is observed, one that is both is verified, and where two sources disagree the disagreement is kept as a drift note rather than resolved silently. That model is planned, not shipped.
Failure modes it would surface
What this source is uniquely good at proving — and, just as usefully, at disproving. An investigation that can refute a hypothesis cheaply is worth as much as one that confirms it. Until the integration ships, the same signals can be checked by hand, or requested by Decim as a check your team runs.
| Failure mode | The signal |
|---|---|
| Job stopped running | Timer disabled, or crontab line commented out |
| Overlapping invocations | A run starting before the previous one finished |
| Silent failure | Non-zero exit with output discarded to /dev/null |
| Environment difference | PATH or locale differing from an interactive shell |
Limits
What this source cannot tell you, even once it is read. Stated because an investigation that overstates its sources produces confident wrong answers, which is worse than an honest cause unclear.
- Plain cron records nothing about a run — no start time, no duration, no exit code
- The planned Linux agent would need to be on the host, or on a host that shares the log volume
- A script's real behaviour is in the script, which may not be in source control either
Related integrations
- SQL Server Agent — Job steps are rows in msdb, not files in git. Will read sysjobs, sysjobsteps and sysjobhistory.
- Apache Airflow — The metadata database holds connections, variables, pools and manual state — none of it in git.
- Custom services — No API and no metadata database — code, logs and the tables they write to. Code and logs work today.
See all integrations, or how the sources are combined into one graph.
Get started
Investigating a cron & systemd timers pipeline?
Bring an incident you already know the answer to. If Decim gets it wrong, that is a more useful demo than one where it doesn't.