JIL One-Time Job Overrides in AutoSys — Temporary Job Changes
- override_job applies a temporary attribute change to the next run of a job, then expires automatically
- The permanent job definition is unchanged — after the overridden run, everything reverts to normal
- Use override_job for one-off changes; use update_job for permanent changes
Sometimes you need to run a job differently for just one execution — a different start time, a different machine, a different command argument — without changing the permanent job definition. That's what one-time overrides are for.
This is a genuinely useful feature that many AutoSys users don't know about. Instead of updating the job, running it, then updating it back, you use override_job to specify the temporary change and it applies only to the next run.
How override_job works
override_job creates a temporary set of attribute changes that apply to the next execution of a job, then expire automatically after that run. The permanent job definition is unchanged.
/* Normal definition: runs at 02:00 daily */ /* override_job: run it at 03:30 just this once */ override_job: daily_report start_times: "03:30" /* Override: run on a different machine for next run only */ override_job: etl_extract machine: etl-server-backup /* Override: temporarily skip a condition for next run */ override_job: generate_summary condition: /* empty condition = no condition for this run */
Override active for next run only. Permanent definition unchanged. */
Viewing active overrides
You can see what overrides are currently active using autorep. This is important to check when a job behaves unexpectedly — it might have an active override you didn't know about.
# See all attributes of a job including any active overrides autorep -J daily_report -d # The -d flag shows 'override' values separately from base values # Look for lines marked with [OVERRIDE] in the output # Check the JIL including overrides autorep -J daily_report -q
start_times: 02:00 [OVERRIDE: 03:30 — active for next run]
machine: report-server-01
owner: reportuser
When to use overrides vs permanent updates
Use override_job when: - You're making a temporary change for one specific run (e.g., running at a different time due to system maintenance) - You need to test a different machine without changing the production definition - You want to skip a dependency condition for a one-off catch-up run
Do NOT use override_job when: - The change is permanent or semi-permanent — use update_job instead - You need to change the change more than 24-48 hours before the job runs — overrides can be confusing if they sit around for days
| Method | Change is permanent? | Affects next run? | Affects future runs? | Use case |
|---|---|---|---|---|
| update_job | Yes | Yes | Yes | Permanent configuration change |
| override_job | No | Yes — next run only | No | One-off temporary change |
| FORCE_STARTJOB sendevent | No | Yes — immediate | No | Manually trigger now, no change to schedule |
🎯 Key Takeaways
- override_job applies a temporary attribute change to the next run of a job, then expires automatically
- The permanent job definition is unchanged — after the overridden run, everything reverts to normal
- Use override_job for one-off changes; use update_job for permanent changes
- Always document active overrides so your team knows why a job might behave differently
⚠ Common Mistakes to Avoid
- ✕Setting an override and forgetting about it — the next run behaves differently and nobody knows why
- ✕Using override_job for a change you actually want to keep permanently — use update_job for that
- ✕Thinking override_job runs the job immediately — it doesn't; it just modifies attributes for when the job next runs according to its normal schedule
- ✕Not documenting that an override was set — causes confusion when the job unexpectedly behaves differently
Interview Questions on This Topic
- QWhat is a JIL one-time override in AutoSys?
- QWhat is the override_job subcommand used for?
- QHow does override_job differ from update_job?
- QHow many times does a one-time override apply?
- QHow do you check if an AutoSys job has an active override?
Frequently Asked Questions
What is a one-time override in AutoSys?
A one-time override lets you change specific attributes of a job for its next execution only. After that run, the job reverts to its permanent definition. Use the override_job JIL subcommand to set one.
Does override_job run the job immediately?
No. override_job only modifies the attributes for the next scheduled run. The job still runs according to its normal start conditions unless you also send a FORCE_STARTJOB event.
How long does an override stay active?
An override stays active until the job runs once (success or failure), then it expires automatically. If the job's next scheduled run hasn't happened yet, the override remains active until that run occurs.
Can I cancel an active override?
You can effectively cancel an override by running update_job on the same attributes — the update_job will replace the override values with whatever you specify. Alternatively, you can delete and re-insert the job if needed.
How do I see if a job has an active override?
Run autorep -J jobname -d which shows detailed job attributes. Active overrides are displayed separately from the base definition. You can also use autorep -J jobname -q to see the JIL including any override settings.
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.