AutoSys ON_ICE vs ON_HOLD — Why Release Timing Skips Jobs

ON_HOLD and ON_ICE are the two ways to suspend a job in AutoSys. They're often confused because both stop a job from running — but their release behaviour is completely different, and choosing the wrong one in a production recovery scenario can cause jobs to either run unexpectedly or not run until the next day. Get this distinction right.

Why ON_ICE Breaks Release Timing While ON_HOLD Doesn't

ON_HOLD and ON_ICE are both job-level conditions that prevent execution, but they differ in how they interact with time-based release logic. ON_HOLD is a simple binary gate: the job stays in a HOLD state until manually released, and when released, it respects all scheduling rules including start times. ON_ICE, however, is a state that cancels the job's current run window entirely. If a job is ON_ICE when its scheduled start time passes, that run is lost — the job will not execute until the next occurrence. This is the core mechanic: ON_ICE skips the current instance, ON_HOLD delays it. In practice, this means ON_ICE is useful for permanently skipping a single run without deleting the job definition, while ON_HOLD is for pausing execution without losing the scheduled trigger. The critical distinction is that ON_ICE does not queue a missed run — it simply discards it.

ON_HOLD — suspend and resume at current conditions

When a job is ON_HOLD, it is frozen in its current state. If you put a job on hold while its starting conditions were already met, releasing it (OFF_HOLD) will cause it to start immediately — the conditions are still true.

# Put a job on hold
sendevent -E JOB_ON_HOLD -J daily_report

# Release from hold — starts immediately if conditions are met
sendevent -E JOB_OFF_HOLD -J daily_report

# Put an entire BOX on hold (and all inner jobs)
sendevent -E JOB_ON_HOLD -J eod_processing_box

# Check if a job is on hold
autorep -J daily_report   # shows OH status

ON_ICE — suspend and wait for next condition cycle

When a job is ON_ICE, it's more deeply suspended. When you release it (OFF_ICE), the job does NOT start immediately — it waits for its conditions to become true in the next scheduling cycle.

For a job with start_times: '02:00', releasing it from ON_ICE at 3 AM means it won't run until the next scheduled 2 AM — it waits for the condition to reoccur, not to re-evaluate it as currently true.

# Put a job on ice
sendevent -E JOB_ON_ICE -J weekly_reconcile

# Release from ice — waits for conditions to reoccur (next cycle)
sendevent -E JOB_OFF_ICE -J weekly_reconcile

# Check if a job is on ice
autorep -J weekly_reconcile   # shows OI status

Which to use when

The decision is simple once you understand the release behaviour:

Use ON_HOLD when: You want to delay a job temporarily and start it manually when ready. Maintenance windows. Jobs you want to run manually at a specific moment after releasing.

Use ON_ICE when: You want to skip a job for the current scheduling period and have it resume at its next normal scheduled time. Disabling a job for a few days without permanently modifying its definition. Safe suspension when you're not sure when you'll release it.

# Scenario 1: Emergency maintenance, want to run job manually when done
# Use ON_HOLD — releases will start immediately when ready
sendevent -E JOB_ON_HOLD -J daily_settlement
# ... do maintenance ...
sendevent -E JOB_OFF_HOLD -J daily_settlement   # starts now

# Scenario 2: Job has a bug being fixed, skip today's run
# Use ON_ICE — releases will wait for tomorrow's scheduled run
sendevent -E JOB_ON_ICE -J daily_settlement
# ... fix deployed by end of day ...
sendevent -E JOB_OFF_ICE -J daily_settlement   # runs tomorrow at 02:00 as normal

How ON_HOLD and ON_ICE affect dependencies

Both statuses affect downstream jobs that depend on the held/frozen job.

When a job is ON_HOLD, it cannot reach SUCCESS or FAILURE, so any downstream jobs that wait for it (via conditions) will remain in a pending state. Releasing from ON_HOLD will start the job, and once it completes, the downstream jobs will then run.

When a job is ON_ICE, same effect — it cannot complete, so dependents wait forever until the job is taken off ice and eventually runs.

The difference: if you put a job ON_HOLD and it already satisfied its own conditions, it will run immediately on release — downstream jobs start soon. If you put it ON_ICE, the job still needs to wait for its next condition cycle, so downstream jobs stay waiting longer.

# Job B depends on Job A
autorep -J Job_B   # Shows status: WAITING (because Job A is ON_HOLD or ON_ICE)

# If Job A is ON_HOLD and you release it:
sendevent -E JOB_OFF_HOLD -J Job_A
# Job A runs now -> succeeds -> Job B starts

# If Job A is ON_ICE and you release it:
sendevent -E JOB_OFF_ICE -J Job_A
# Job A waits until next scheduled time -> only then runs -> Job B waits even longer

Debugging jobs that won't start — hold/ice troubleshooting

When a job doesn't start and you suspect a hold or ice status, follow these steps:

1. Run autorep -J jobname and look for ST column — OH or OI indicates the job is held/iced.
2. Check the status of any parent box: autorep -J boxname — if the box is OH/OI, inner jobs are blocked even if they look normal.
3. Review sendevent history to see who set the hold/ice: check autorep logs or event trail.
4. If a box is held and you release it, inner jobs might start immediately based on their own conditions — be cautious.

To clear a hold: sendevent -E JOB_OFF_HOLD -J jobname To clear ice: sendevent -E JOB_OFF_ICE -J jobname

# Check job status
autorep -J daily_report
# Output: ... ST: OH ... -> ON_HOLD

# Check box status (inner jobs may be blocked)
autorep -J batch_box

# Check event history (if available)
autorep -J daily_report -w -r

# Force a job ON_HOLD if it's ON_ICE? Not possible directly; must clear ice first.
sendevent -E JOB_OFF_ICE -J daily_report
# Then optionally set hold: sendevent -E JOB_ON_HOLD -J daily_report

The Silent Killer: How ON_ICE Masks Dependency Failures

You think ON_ICE is just a pause button. It's not. It's a time bomb for your dependency chain.

When you put a job ON_ICE, Autosys still evaluates its start conditions. It checks file triggers, time windows, and upstream job status. But instead of starting, it sits there — satisfied but silent. Every cycle, it re-evaluates. Every cycle, it finds the conditions met. Every cycle, it does nothing.

Meanwhile, the downstream jobs that depend on that box? They see it as "not running" — not failed, not success, just… nothing. So they wait. Forever. Unless you put them on a time-based override or manually intervene.

ON_HOLD doesn't have this problem. It never evaluates conditions. The job is frozen in time. Dependencies are explicitly broken until you release it. No ambiguity, no silent waits.

If you're debugging a chain where jobs won't start despite all conditions being green, check for ON_ICE. It's the job that's smiling and doing nothing.

// io.thecodeforge — devops tutorial
// Job A is ON_ICE — it meets conditions but won't run
job_name: A
condition: s(B) && s(C)
status: ON_ICE
start_times: "09:00, 10:00, 11:00"

// Job D waits for A — forever
job_name: D
condition: s(A)
status: INACTIVE
// D never starts because A never sends success

Racing the Clock: Why ON_ICE Wrecks Scheduled Start Times

Here's the scenario: You have a job scheduled at 03:00, 06:00, 09:00. At 02:55, the upstream fails. You put it ON_ICE to debug. Problem solved, right? Wrong.

ON_ICE doesn't discard the missed start time. It holds the job in a state of 'conditions met, start time evaluated'. When you take it off ice at 10:00, Autosys says: "Last start condition matched at 09:00. That window is closed. You missed it." The job won't run until the next scheduled start — 03:00 tomorrow.

ON_HOLD is different. It never evaluates start times. When you release it at 10:00, Autosys checks: "Is it 10:00? Yes. Is conditions met? Check. Run." The job fires immediately if conditions are satisfied.

This is why release engineers hate ON_ICE during change windows. You're racing against the clock. Miss a start time, and you're waiting hours for the next cycle. With ON_HOLD, you control when it runs.

Rule: If you need to pause a time-critical batch and resume the same day, use ON_HOLD. If you're okay waiting for the next scheduled window, ON_ICE is fine.

// io.thecodeforge — devops tutorial
// Job has 3 start times daily, put ON_ICE at 02:55
job_name: nightly_batch
description: Runs at 03:00, 06:00, 09:00
status: ON_ICE
start_times: "03:00, 06:00, 09:00"

// Released at 10:00 — Autosys sees no future start until 03:00 next day
// With ON_HOLD instead, released at 10:00 — runs immediately