Force Start and Kill Jobs in AutoSys — Operational Control
- FORCE_STARTJOB starts immediately bypassing all conditions — know what you're bypassing before using it in production
- KILLJOB terminates a running job and moves it to TERMINATED — downstream success() conditions will not be met
- RESTART is the clean way to retry a FAILURE or TERMINATED job after fixing the root cause
Production AutoSys environments need regular manual intervention — jobs that need to be rerun after a fix, jobs that hung and need to be killed, jobs that need to be triggered outside their normal schedule. Knowing the exact commands for each scenario, and understanding the side effects, is what separates a reactive operator from a skilled one.
FORCE_STARTJOB — bypassing all conditions
FORCE_STARTJOB immediately starts a job regardless of its date_conditions, start_times, or condition dependencies. It's the 'run it now, no questions asked' command.
# Force start a single job immediately sendevent -E FORCE_STARTJOB -J daily_report # Force start a BOX (starts the box, inner jobs still follow their conditions) sendevent -E FORCE_STARTJOB -J eod_processing_box # Force start on a specific date (run it as if it were that date) sendevent -E FORCE_STARTJOB -J daily_report -q 20260319 # Check it started autorep -J daily_report
/* Job daily_report: STARTING → RUNNING (02:00:01) */
KILLJOB — terminating a running job
KILLJOB sends a termination signal to the process running on the agent machine. The job moves to TERMINATED status. Any downstream jobs waiting on success() of this job will not start.
# Kill a running job sendevent -E KILLJOB -J hung_etl_job # After killing, check status autorep -J hung_etl_job # If you need downstream jobs to proceed after kill: # First kill the job, then manually mark it as success sendevent -E KILLJOB -J hung_etl_job sendevent -E CHANGE_STATUS -J hung_etl_job -s SUCCESS
hung_etl_job TE -- <- TERMINATED after KILLJOB
RESTART — retrying a failed job
The RESTART event tells AutoSys to rerun a job that is in FAILURE or TERMINATED status. It's cleaner than FORCE_STARTJOB for rerunning failed jobs because it respects that this is a retry of a previously failed run.
# Restart a failed job sendevent -E RESTART -J failed_extract_job # This is equivalent to force-starting but signals intent as a retry # Most useful in scripts that check status and auto-retry # Pattern: check for failures and restart them autorep -J % -s FA | awk '{print $1}' | while read job; do echo "Restarting failed job: $job" sendevent -E RESTART -J "$job" done
Restarting failed job: load_positions
| Event | Respects conditions? | Works on status | Typical use |
|---|---|---|---|
| FORCE_STARTJOB | No — bypasses all | Any non-running state | Run now outside normal schedule |
| STARTJOB | Yes | INACTIVE / ACTIVATED | Trigger when conditions might be met |
| RESTART | No — retries directly | FAILURE / TERMINATED | Retry after fixing root cause |
| KILLJOB | N/A | RUNNING only | Terminate a hung or errant job |
| CHANGE_STATUS + SUCCESS | N/A | Any | Unblock dependencies after manual fix |
🎯 Key Takeaways
- FORCE_STARTJOB starts immediately bypassing all conditions — know what you're bypassing before using it in production
- KILLJOB terminates a running job and moves it to TERMINATED — downstream success() conditions will not be met
- RESTART is the clean way to retry a FAILURE or TERMINATED job after fixing the root cause
- To unblock dependencies after a kill, use CHANGE_STATUS -s SUCCESS after the KILLJOB
⚠ Common Mistakes to Avoid
- ✕Force-starting a job without understanding what dependency conditions it's bypassing — this is how data integrity issues happen
- ✕Killing a job in a BOX without accounting for the box going to FAILURE — check if downstream jobs are blocked
- ✕Using RESTART instead of FORCE_STARTJOB when the job is INACTIVE — RESTART works on failed/terminated jobs; FORCE_STARTJOB works on anything
- ✕Not checking the error log before restarting a FAILURE — the restart will fail again for the same reason
Interview Questions on This Topic
- QWhat is the difference between FORCE_STARTJOB and STARTJOB?
- QWhat happens to a job's status after KILLJOB?
- QWhat is the difference between RESTART and FORCE_STARTJOB for a failed job?
- QHow would you unblock dependent jobs after a job was killed?
- QIf term_run_time terminates a job, what status does it move to?
Frequently Asked Questions
How do I force start an AutoSys job from the command line?
Use sendevent -E FORCE_STARTJOB -J jobname. This starts the job immediately, bypassing all starting conditions including date_conditions, start_times, and condition dependencies.
What happens after KILLJOB in AutoSys?
The job moves to TERMINATED status. Any downstream jobs with condition: success(killed_job) will not run because success was never declared. If you need downstream jobs to proceed, manually mark the killed job as SUCCESS with sendevent -E CHANGE_STATUS -J jobname -s SUCCESS.
What is the difference between RESTART and FORCE_STARTJOB?
Both effectively run the job immediately. RESTART is semantically a retry — designed for FAILURE or TERMINATED jobs after a fix. FORCE_STARTJOB is a direct start from any state. In practice, RESTART is the preferred command for rerunning failed jobs as it's clearer in audit logs.
Can I force start a job that is inside a BOX?
Yes, but the BOX must also be in RUNNING state for the inner job to start properly. If you force-start a job inside a non-running box, the job may start but the box won't register the run as part of its flow. Usually better to FORCE_STARTJOB the box rather than individual inner jobs.
What status does a job have after term_run_time kills it?
TERMINATED (TE). The exit code will be -1 or a signal number. Check autorep -J jobname -d to see the exact exit code and confirm it was term_run_time that caused it.
Developer and founder of TheCodeForge. I built this site because I was tired of tutorials that explain what to type without explaining why it works. Every article here is written to make concepts actually click.