Schedulers
SQL Server Agent — planned
Job steps are rows in msdb, not files in git. Will read sysjobs, sysjobsteps and sysjobhistory. This integration is planned: documented here as reference, not connectable from the admin today.
A SQL Agent job is not a file. It is a set of rows in msdb, created
through a dialog box, and in most estates there is no copy of it anywhere else. The step
commands — frequently the actual ETL logic — live in
msdb.dbo.sysjobsteps.command.
This is also why discovery from the repository alone — which is how Decim finds pipelines today — cannot see a SQL Agent job. There is nothing in git to read. The definition that runs your nightly load exists in exactly one place, and it is a table; reading it is what this planned integration is for.
SQL Server Agent today
Decim does not read msdb today, and pipeline discovery reads code only, so a
job defined only in SQL Agent is not seen as a pipeline. The procedures a job step calls are
read if they are kept in a connected GitHub repository. On a Windows host, the optional agent
can read step output files and the Windows Application event log, where SQL Agent records job
failures when a job is set to. Job history can also be exported and attached to the
incident.
The sources that ship today are GitHub, Google Cloud Logging, Jira Cloud and the optional Windows agent. Everything below this point describes the planned SQL Server Agent integration: what it is designed to read, and why.
What Decim will read from SQL Server Agent
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 |
|---|---|---|
| Job definitions | msdb.dbo.sysjobs | Name, owner, enabled state, description |
| Step commands | msdb.dbo.sysjobsteps | The actual command text — often the ETL itself |
| Run history | msdb.dbo.sysjobhistory | Outcome, duration and message per step per run |
| Live activity | msdb.dbo.sysjobactivity | What is executing now, and what last ran |
| Schedules | msdb.dbo.sysschedules | Frequency, interval and start time |
| Step flow | sysjobsteps.on_success_action | Branching between steps — control edges |
| Proxies | msdb.dbo.sysproxies | Which credential a step runs under |
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.
USE msdb;
CREATE USER decim_agent FOR LOGIN decim_agent;
GRANT SELECT ON dbo.sysjobs TO decim_agent;
GRANT SELECT ON dbo.sysjobsteps TO decim_agent;
GRANT SELECT ON dbo.sysjobhistory TO decim_agent;
GRANT SELECT ON dbo.sysjobactivity TO decim_agent;
GRANT SELECT ON dbo.sysschedules TO decim_agent;
GRANT SELECT ON dbo.sysjobschedules TO decim_agent;
-- SQLAgentReaderRole is the alternative and grants more than the above.
-- Prefer explicit table grants; role membership is harder to audit.What it would build
What this source would contribute to the pipeline topology and to the evidence available during an investigation:
- Control edges between steps, including failure branches
- Transform nodes from step command text
- Schedules, which is how a stall with a clock gets explained
- Run outcomes and durations for anomaly detection
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 silently disabled | sysjobs.enabled = 0 with no failure anywhere |
| Step succeeded doing nothing | Duration far below the step's own history |
| Job overlapped itself | Two run instances with overlapping windows |
| Step failure swallowed | on_fail_action set to continue to the next step |
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.
sysjobhistoryis trimmed by agent history limits — often 1,000 rows total, which on a busy instance is days rather than months- A job deleted and recreated loses all prior history and gets a new
job_id - Step output files written to disk are not in
msdband need filesystem access to read
Related integrations
- SQL Server — Will read catalog metadata, procedure bodies and write activity — the definitions git never sees.
- SSIS — SSISDB holds executions, per-component row counts and the parameter values actually used.
- cron & systemd timers — The scheduler with no database. Will read crontabs, timer units and journal history.
See all integrations, or how the sources are combined into one graph.
Get started
Investigating a SQL Server Agent 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.