Create a job with a single step. On the advanced tab for that step, change retry attempts from 0 to something greater than 0. In the job step, have it be your SELECT SELECT. Run the job. You will see an entry .

I don't think anyone could provide a full list of all scenarios that could lead to the various possible status values. Did you try anything like this while a job was running (and it's easy to test this with a simple job that has a loop with SELECT TOP (1) name FROM somedb.sys.all_objects;WAITFOR DELAY '00:00:01';); things like:

• unplugging the computer
• failing over (cluster or AG)
• setting somedb to single_user or offline
• killing sqlservr.exe process or shutting down the agent service
• having the step raising batch- and connection-aborting errors
• having the step raise an exception that causes "severe error" or assertion check failures (assuming there are some that exist and you can repro on your version)

Create a job with a single step. On the advanced tab for that step, change retry attempts from 0 to something greater than 0. In the job step, have it be your SELECT SELECT. Run the job. You will see an entry .

I don't think anyone could provide a full list of all scenarios that could lead to the various possible status values. Did you try anything like this while a job was running (and it's easy to test this with a simple job that has a loop with SELECT TOP (1) name FROM somedb.sys.all_objects;WAITFOR DELAY '00:00:01';); things like:

• unplugging the computer
• failing over (cluster or AG)
• setting somedb to single_user or offline
• killing sqlservr.exe process or shutting down the agent service
• having the step raising batch- and connection-aborting errors
• having the step raise an exception that causes "severe error" or assertion check failures (assuming there are some that exist and you can repro on your version)

run_status is useful, but you can get a better picture from the combination of run_status and message (and, in severe cases, the SQL Server error log). The trouble with message is that the contents can get truncated, so if you have a step that performs 400 successful backups and then one fails, the content will be full of successful messages, and the failure will be missing. For important jobs you may want to log to a table or to a file; you can see a variety of options on the Advanced tab of any job step.

Create a job with a single step. On the advanced tab for that step, change retry attempts from 0 to something greater than 0. In the job step, have it be your SELECT SELECT. Run the job. You will see an entry .

I don't think anyone could provide a full list of all scenarios that could lead to the various possible status values. Did you try anything like this while a job was running (and it's easy to test this with a simple job that has a loop with SELECT TOP (1) name FROM somedb.sys.all_objects;WAITFOR DELAY '01:00:00';); things like:

• unplugging the computer
• failing over (cluster or AG)
• setting somedb to single_user or offline
• killing sqlservr.exe process or shutting down the agent service
• having the step raising batch- and connection-aborting errors
• having the step raise an exception that causes "severe error" or assertion check failures (assuming there are some that exist and you can repro on your version)

Create a job with a single step. On the advanced tab for that step, change retry attempts from 0 to something greater than 0. In the job step, have it be your SELECT SELECT. Run the job. You will see an entry .

I don't think anyone could provide a full list of all scenarios that could lead to the various possible status values. Did you try anything like this while a job was running (and it's easy to test this with a simple job that has a loop with SELECT TOP (1) name FROM somedb.sys.all_objects;WAITFOR DELAY '00:00:01';); things like:

• unplugging the computer
• failing over (cluster or AG)
• setting somedb to single_user or offline
• killing sqlservr.exe process or shutting down the agent service
• having the step raising batch- and connection-aborting errors
• having the step raise an exception that causes "severe error" or assertion check failures (assuming there are some that exist and you can repro on your version)