SSIS Job Disagreement
Overview
Everything downstream of an Agent job trusts the job. Operators are paged on it, dashboards are green because of it, and an SSIS step that does not propagate its package’s failure makes all of that quietly wrong.
It is a two line fix on the step and nobody finds it, because finding it means comparing two systems that nothing compares.
Where to find it
Expand a server in the tree, expand a database holding an Integration Services catalog, then SSIS → Job Disagreement.
Three causes, separated, because they have different fixes
The step walked past the failure
The step’s on-failure action was left at go to the next step, so the job walked past a failed package and ended green.
The step did not wait
The step started the execution with SYNCHRONIZED off, which returns the moment the execution is created. The step cannot know how the package went because the package had not started.
The job failed for its own reasons
The job failed on a later step while the package was fine. That is the mirror image, and it sends somebody to the wrong place just as effectively.
The match is an inference and is labelled as one throughout
SSIS does not record the job.
What it records is a step whose command names the package, which is the same /ISSERVER match SSIS Schedule makes, and this page reuses it.
Nothing on this page presents the match as a fact.
Reading the grid
| Column | What it is |
|---|---|
| When | The night in question. |
| Job | The Agent job. |
| Step | The SSIS step inside it. |
| The job said | The job’s outcome: succeeded, failed, canceled. |
| Package | The package the step names. |
| The package said | The execution’s status, decoded. |
| Why they disagree | Which of the three causes this row is. |
| Execution | The execution_id, so the run can be opened on the other pages. |
The toolbar
| Control | Options | Default |
|---|---|---|
| Window | 7 days, 30 days, 90 days | 30 days |
| How to fix a step | Explains the two settings behind the first two causes. | |
| Failures | Opens SSIS Package Failures. |
Where the data comes from
| Source | What it gives |
|---|---|
catalog.executions |
The package’s real status, start and end. |
msdb.dbo.sysjobsteps |
The /ISSERVER command, the on_fail_action, and the step’s own settings. |
msdb.dbo.sysjobhistory |
What the job and the step reported. |
msdb.dbo.sysjobs |
The job names. |
The Agent time encoding. run_date and run_time are integers holding yyyymmdd and hhmmss, and lining an Agent run up against a catalog timestamp means converting them properly first.
Related reports
| Report | Why you would go there |
|---|---|
| SSIS Package Failures | What the package actually said while the job was green. |
| SSIS Schedule | The same job-to-package match, for the whole schedule. |
| SSIS Reruns | Whether a retry hid the failure as well. |
| Job Step Failures | The Agent side of a step that did fail. |
| Failed Jobs | The jobs that reported failure honestly. |
Frequently asked questions
The job is green every morning and the data is stale. This is the page. Look at the Why they disagree column: either the step walked past the failure or it never waited to see one.
How do I fix “did not wait”? The step started the execution with SYNCHRONIZED off. Turning it on makes the step wait for the execution and report its result.
How do I fix “walked past”? The step’s on-failure action. Set it to quit the job reporting failure instead of go to the next step.
A row shows the job failing while the package succeeded. Then something else in the job failed, on a later step. The package is not your problem, and without this page somebody would have spent the morning proving that.