Schedulers
SSIS — planned
SSISDB holds executions, per-component row counts and the parameter values actually used. This integration is planned: documented here as reference, not connectable from the admin today.
The .dtsx file may well be in source control. What is not in source
control is which version was deployed, which parameter values were supplied at execution, and
which environment reference was bound — all of which live in SSISDB and any of
which can change behaviour completely.
SSIS is also unusual in offering per-component row counts natively. Where logging level
permits, catalog.execution_data_statistics records how many rows crossed each
path between components, which is exactly the reconciliation most stacks make you infer.
SSIS today
Decim does not read scheduler catalogs today, and pipeline discovery reads code only, so a job defined only inside the scheduler is not seen as a pipeline. What works now: logic kept in a connected GitHub repository is read as code; job output written to files or to the Windows Event Log on a Windows host can be read through the optional agent; and job history can be exported and attached to the incident as a file (up to 500 MB each).
The sources that ship today are GitHub, Google Cloud Logging, Jira Cloud and the optional Windows agent. Everything below this point describes the planned SSIS integration: what it is designed to read, and why.
What Decim will read from SSIS
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 |
|---|---|---|
| Executions | catalog.executions | Package, project, folder, status, start and end |
| Component timings | catalog.executable_statistics | Per-executable duration and result |
| Row counts per path | catalog.execution_data_statistics | Rows crossing each data-flow path — the native reconciliation |
| Parameter values used | catalog.execution_parameter_values | What was actually supplied, not what the package defaults to |
| Messages | catalog.event_messages | Warnings and errors per execution |
| Project versions | catalog.object_versions | Which build was deployed, and when |
| Environment bindings | catalog.environment_references | Which environment supplied the values |
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 SSISDB;
CREATE USER decim_agent FOR LOGIN decim_agent;
-- ssis_logreader gives read access to the execution and logging views
-- without any ability to execute or deploy packages.
ALTER ROLE ssis_logreader ADD MEMBER decim_agent;
-- Catalog views are also readable individually if you prefer explicit grants:
GRANT SELECT ON catalog.executions TO decim_agent;
GRANT SELECT ON catalog.executable_statistics TO decim_agent;
GRANT SELECT ON catalog.execution_data_statistics TO decim_agent;
GRANT SELECT ON catalog.execution_parameter_values TO decim_agent;
GRANT SELECT ON catalog.event_messages TO decim_agent;What it would build
What this source would contribute to the pipeline topology and to the evidence available during an investigation:
- Data-flow topology with genuine per-path row counts
- The parameter values that actually applied to a given run
- Deployment history, correlatable against an incident window
- Component-level 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 |
|---|---|
| Wrong environment bound | Parameter values differing from the previous good run |
| Rows lost between components | Path counts diverging inside one data flow |
| Package succeeded with zero rows | Execution success with all path counts at zero |
| Redeployment mid-incident | New row in object_versions inside the window |
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.
- Package-deployment-model (legacy) packages do not use SSISDB at all and leave only what their own logging captured
- SSISDB retention defaults to 365 days but the cleanup job is often disabled or failing — verify rather than assume
- Script components are compiled and their logic is not readable from the catalog
Related integrations
- SQL Server Agent — Job steps are rows in msdb, not files in git. Will read sysjobs, sysjobsteps and sysjobhistory.
- SQL Server — Will read catalog metadata, procedure bodies and write activity — the definitions git never sees.
- Azure Data Factory — Pipeline JSON lives in the factory unless git integration is enabled — and live mode is the default.
See all integrations, or how the sources are combined into one graph.
Get started
Investigating a SSIS 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.