AutoSys Override Trap — Active Override Overrules Permanent

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 AutoSys Override Priority Actually Works

A one-time job override in AutoSys JIL is a temporary modification to a job's attributes that takes effect for a single execution only. The critical mechanic: an active override always takes precedence over the permanent job definition, regardless of when it was applied. This means if you set an override while the job is already running, that override will apply to the current run — not the next one.

Key properties: overrides are stored separately from the base job definition and persist until explicitly removed or the job runs. They do not survive a job restart or a JIL update. An override can target any attribute that the jil command supports: start_times, condition, owner, max_run_alarm, etc. Once the job completes, the override is automatically cleared.

Use overrides for emergency fixes — e.g., temporarily changing a job's start time to avoid a holiday, or overriding a condition to force-run a job after a dependency failure. They are not a substitute for permanent JIL changes. In production, overrides are a common source of confusion because engineers forget they applied one, then wonder why the job behaves differently on 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. The override is stored in AutoSys's Event Server as a separate record keyed by job name. It's conceptually like a sticky note — attached until the job runs once, then discarded.

You can override any attribute that is normally set with insert_job or update_job: start_times, condition, machine, command, owner, etc. Multiple attributes can be overridden in one override_job statement by listing them each on a new line after the override_job: directive.

/* 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 */

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. The -d (detail) flag shows overrides separately from base values, while -q (JIL query) shows the full effective JIL including any overrides merged in.

# 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

When to use overrides vs permanent updates

Cancelling an active override

There is no direct 'cancel override' command. To remove an active override, you have two options:

1. Run update_job on the same attributes that were overridden. update_job will overwrite the override value and reset the attribute to its new permanent value. The override record is then removed.
2. Run override_job again with the original permanent values. This creates a new override that cancels the effect of the previous one. After the next run, both overrides are consumed.

Option 1 is cleaner and recommended. Option 2 can lead to a chain of overrides that becomes hard to track.

You cannot simply delete an override record via JIL — it's not a separate object. It's attached to the job until the job runs or is updated.

# Option 1: Use update_job to replace the overridden attribute permanently
update_job: daily_report
start_times: "02:00"

# This will also remove the active override for start_times
# After this, the job will use 02:00 permanently.

# Option 2: Override with the original value (if you want to keep the permanent as-is)
override_job: daily_report
start_times: "02:00"
# Now the override matches the permanent — both are 02:00.
# After next run, override expires and permanent value is still 02:00.

Best practices and common pitfalls

Centralise override documentation — every override should be logged in a shared channel or incident tracker. This prevents the 'mysterious behaviour' scenario.

Set a TTL reminder: if you set an override more than a day before the job runs, set a calendar reminder to verify it's still needed.

Avoid overriding condition unless you fully understand the dependency chain. An empty condition can cause a job to run out of order and break downstream processes.

Use a script to list all active overrides across your environment periodically (autorep -J ALL -d | grep OVERRIDE). This catches forgotten overrides before they cause issues.

# List all jobs with active overrides
autorep -J ALL -d | grep -B5 "OVERRIDE" | grep "Job Name" | awk '{print $NF}'

Why Override Priorities Break Down in Multi-Team Pipelines

You've got three teams pumping jobs into the same AutoSys instance. Each team thinks their override is the most important thing in the world. But AutoSys doesn't have a 'my team is special' flag. Priority is global. When Team Alpha overrides job 'payment_export' to priority 100 and Team Beta overrides the same job to 50 five minutes later, the last writer wins. No merge. No conflict resolution. The job runs at 50. Team Alpha's critical batch explodes at 3 AM. This isn't a bug. It's a coordination failure. Before you teach everyone how to override, you need a single source of truth for who owns each job's priority. Otherwise you're just letting people overwrite each other in the dark. Use a shared config file or a tool like Rundeck that enforces approvals. But whatever you do, don't rely on tribal knowledge. It's a lie. The fix is simple: document ownership in the job definition itself. Add a 'owner' attribute. Then build a small script that rejects overrides from non-owners. AutoSys can't do that for you. You have to build the guardrails yourself.

// io.thecodeforge — devops tutorial

// Reject override if requester isn't the job owner
// Run this as a pre-processing step before applying any override

job: payment_export
owner: team_alpha_ops
override_request:
  requested_by: team_beta_dev
  new_priority: 100

check_result: |
  REJECTED: team_beta_dev is not authorized to override payment_export
  Job owner: team_alpha_ops
  Action: Notify team_alpha_ops via Slack #ops-alerts

How to Safely Test Override Priority Before It Hits Production

You wouldn't push a code change without staging. Yet I've seen seniors blast an override straight into prod. Then they wonder why the daily ETL runs at priority 200 and starves every other job on the box. Stop. Testing an override is cheaper than rolling back a broken batch. Here's the pattern: create a duplicate job with '_test' suffix in a separate instance. Match its resource profile — CPU, memory, dependencies — to the production job. Apply your override there. Run it. Watch the system. Does it complete before other jobs? Does it cause resource contention? Now you know. If you can't duplicate, use AutoSys' 'dry_run' flag on the sendevent command. It validates syntax and shows you what the override would do without executing. Most people don't know that exists. It's in the docs on page 47. Read the docs. After testing, document the expected behavior in your runbook: 'At priority 90, job X finishes in 12 minutes. At 150, it finishes in 8 but delays job Y by 20%'. That data is gold. Without it, you're guessing. And guessing in production gets you paged.

// io.thecodeforge — devops tutorial

// Test override without applying it
// Use dry_run to validate priority impact

command: sendevent -E OVERRIDE_PRIORITY -J payment_export -P 150 -dry_run TRUE

expected_dry_run_output: |
  Dry run successful
  Event: OVERRIDE_PRIORITY
  Job: payment_export
  New Priority: 150
  Current Priority: 50
  No changes applied. Job continues running at 50.
  Estimated resource impact: High — may delay 3 dependent jobs.