DevOps Intermediate

AutoSys sendevent Command — Complete Reference

Q: How do I manually start an AutoSys job from the command line?

Use `sendevent -E FORCE_STARTJOB -J jobname` to start immediately regardless of conditions, or `sendevent -E STARTJOB -J jobname` to start only if conditions are met.

Q: How do I stop the AutoSys Event Processor?

Use `sendevent -E STOP_DEMON`. This sends a graceful shutdown signal. Never use kill -9 — it can leave jobs in inconsistent states requiring manual cleanup before restart.

📅 March 19, 2026 ⏱ 3 min read 🎯 Intermediate

Where developers are forged. · Structured learning · Free forever.

📍 Part of: AutoSys → Topic 19 of 30

The AutoSys sendevent command controls job events: start, kill, hold, ice, force start, and more.

⚙️ Intermediate — basic DevOps knowledge assumed

In this tutorial, you'll learn

The AutoSys sendevent command controls job events: start, kill, hold, ice, force start, and more.

sendevent is the primary command for manually controlling AutoSys job execution and state
FORCE_STARTJOB bypasses all conditions; STARTJOB respects them — use FORCE_STARTJOB carefully in production
CHANGE_STATUS -s SUCCESS is a recovery tool to unblock dependency chains when a job was fixed manually

thecodeforge.io

sendevent Event Types

Autosys Sendevent Command

✦ Plain-English analogy ✦ Real code with output ✦ Interview questions

⚡Quick Answer

sendevent sends signals to the AutoSys Event Processor to control jobs
Common events: FORCE_STARTJOB, STARTJOB, KILLJOB, JOB_ON_HOLD, CHANGE_STATUS
Use -E for event type and -J for job name; -S for instance name
Performance: bulk events without sleep can overwhelm the Event Processor queue
Production insight: sending FORCE_STARTJOB when dependencies are unmet can cause silent data corruption
Biggest mistake: assuming STARTJOB runs the job immediately — it only works if conditions are satisfied

🚨 START HERE

sendevent Quick Debug Cheat Sheet

Copy-paste commands for the most common sendevent problems

🟡

Event sent but job status unchanged

Immediate ActionCheck if Event Processor is alive and job name is correct

Commands

autorep -q jobname | grep -E 'Status|Event'

autorep -W -s ALL | grep jobname

Fix NowResend with -S instance if multi-instance; verify job name spelling

🟡

FORCE_STARTJOB looks ignored

Immediate ActionCheck if job is ON_HOLD or ON_ICE — that prevents any event except JOB_OFF_HOLD/OFF_ICE

Commands

autorep -q jobname | grep -i 'hold\|ice'

sendevent -E JOB_OFF_HOLD -J jobname

Fix NowRelease from hold/ice first, then FORCE_STARTJOB

🟡

Downstream job not running after CHANGE_STATUS SUCCESS

Immediate ActionCheck if downstream job has additional time or alarm conditions

Commands

autorep -j downstream_job | grep -E 'Condition|Start_times|date_conditions'

sendevent -E STARTJOB -J downstream_job

Fix NowIf conditions are met, STARTJOB triggers immediate execution

🟡

sendevent hangs with no output

Immediate ActionCheck network connectivity and Event Processor status

Commands

ping event_processor_host # or check $AUTOUSER/.autosys

ps -ef | grep autoevent*

Fix NowRestart Event Processor only if necessary: sendevent -E STOP_DEMON then autostart via script

Production Incident

The midnight FORCE_STARTJOB that ran ETL before the source data arrived

An engineer used FORCE_STARTJOB to restart a failed nightly ETL job. The job ran immediately — but the upstream file hadn't been uploaded yet.

SymptomETL job completed with zero rows. Downstream reports showed missing data for 12 hours.

AssumptionFORCE_STARTJOB is safe because the job had already run earlier that day.

Root causeFORCE_STARTJOB bypasses all conditions — including file_watcher and calendar dependencies. The job ran before the external file was present.

FixUse sendevent -E RESTART -J jobname which respects conditions. Alternatively, verify the upstream state manually before forcing.

Key Lesson

FORCE_STARTJOB is for emergencies — always verify the reason the job is waiting firstWhen in doubt, use STARTJOB or RESTART, not FORCE_STARTJOBDocument in your runbook: which jobs can be force-started and which cannot

Production Debug Guide

Symptom → Action guide for when events don't work as expected

sendevent returns immediately but job doesn't change state→Check autorep -q jobname to see if event was queued. If not, verify Event Processor is running with autorep -W.

sendevent -E STOP_DEMON doesn't stop Event Processor→You may have sent to the wrong instance. Use -S with the correct instance name. If still not stopping, check the event log at $AUTOUSER/events.

Job receives FORCE_STARTJOB but never starts→Check if the job's status is INACTIVE or SUCCESS — FORCE_STARTJOB may not apply. Use JOB_ON_ICE first? Verify with autorep -q.

CHANGE_STATUS -s SUCCESS doesn't unblock downstream jobs→Downstream jobs may be waiting on additional conditions (e.g., date_conditions, alarms). Use autorep -j downstream_job and look at the 'Conditions' column.

sendevent is one of the most frequently used AutoSys commands in day-to-day operations. Every manual job control action — starting a job, putting it on hold, killing it, setting a global variable — goes through sendevent. It's the command-line interface to the AutoSys event system. If you've ever triggered a production outage because you sent the wrong event, you know exactly why this reference exists.

sendevent syntax and key options

The basic syntax is: sendevent -E event_type -J job_name. The -E flag specifies the event type, -J the job name. Most commands also support -S for the AutoSys instance name if you have multiple environments. Always use single quotes around job names if they contain special characters. The event types are case-sensitive — KILLJOB works, killjob doesn't.

sendevent_syntax.sh · BASH

12345678910111213141516171819202122232425262728293031323334353637383940

# Basic syntax
sendevent -E EVENT_TYPE -J job_name

# For a specific AutoSys instance
sendevent -E EVENT_TYPE -J job_name -S INSTANCE_NAME

# ── The most common sendevent operations ──────────────────────────

# Force start a job (run immediately regardless of conditions)
sendevent -E FORCE_STARTJOB -J daily_report

# Start a job normally (only if conditions are met)
sendevent -E STARTJOB -J daily_report

# Kill a running job
sendevent -E KILLJOB -J daily_report

# Put a job on hold (won't run until released)
sendevent -E JOB_ON_HOLD -J daily_report

# Release a job from hold
sendevent -E JOB_OFF_HOLD -J daily_report

# Put a job on ice (stronger suspension)
sendevent -E JOB_ON_ICE -J daily_report

# Release from ice
sendevent -E JOB_OFF_ICE -J daily_report

# Delete a job via event
sendevent -E DELETEJOB -J old_legacy_job

# Manually change a job's status
sendevent -E CHANGE_STATUS -J job_name -s SUCCESS

# Set a global variable
sendevent -E SET_GLOBAL -G "TRADE_COUNT=5432"

# Stop the Event Processor gracefully
sendevent -E STOP_DEMON

⚠ FORCE_STARTJOB vs STARTJOB

STARTJOB only works if the job's starting conditions are currently met. FORCE_STARTJOB bypasses all conditions and starts the job immediately. Use FORCE_STARTJOB with caution in production — you're deliberately skipping the dependency checks that are there for a reason.

📊 Production Insight

Sending events to the wrong instance is the #1 cause of sendevent 'not working'.

Always use -S when your environment has multiple AutoSys instances (dev, test, prod).

Tip: set $AUTOSYS in your shell to avoid forgetting.

🎯 Key Takeaway

Flag order doesn't matter, but case does.

Get into the habit of: sendevent -E EVENT -J job -S instance.

That pattern catches 90% of execution errors.

CHANGE_STATUS — manually overriding job status

CHANGE_STATUS lets you manually set a job to SUCCESS or FAILURE. This is used in recovery scenarios: if a job failed but the issue has been resolved manually outside AutoSys, you can mark it SUCCESS so downstream jobs can proceed. But be careful: you're lying to the scheduler, and downstream jobs may trust the data that never arrived. Use it only when you have verified the work is complete.

change_status.sh · BASH

12345678

# Manually mark a job as SUCCESS (to unblock downstream dependencies)
sendevent -E CHANGE_STATUS -J extract_job -s SUCCESS

# Manually mark a job as FAILURE (to block downstream from starting)
sendevent -E CHANGE_STATUS -J questionable_job -s FAILURE

# After CHANGE_STATUS to SUCCESS, downstream jobs that were waiting
# will now evaluate their conditions and may start automatically

▶ Output

/* Event processed: extract_job status changed to SUCCESS
Downstream job 'transform_job' condition now met — starting */

🔥When CHANGE_STATUS to SUCCESS is appropriate

Use CHANGE_STATUS to SUCCESS when: a job failed due to an infrastructure issue (disk full, network blip) but the actual data processing completed successfully; or you need to unblock a dependency chain while a failed job is being investigated and fixed manually.

📊 Production Insight

CHANGE_STATUS to FAILURE is safer than SUCCESS — it forces explicit investigation.

Many teams have been burned by marking a job SUCCESS only to find it didn't actually run.

Always e-mail the team or enter a ticket before changing job status.

🎯 Key Takeaway

CHANGE_STATUS is a surgical knife, not a hatchet.

Use -s FAILURE to stop a chain, -s SUCCESS only when the work is verified.

One misapplied SUCCESS can corrupt downstream data for hours.

Using sendevent in shell scripts for automation

sendevent becomes especially powerful when used inside shell scripts for batch recovery automation. Instead of manually sending events one by one, you can script common operational patterns — like automatically restarting all failed jobs, or setting a global variable and triggering a downstream job in sequence. But there are traps: looping without a sleep can flood the Event Processor, and forgetting to quote variable expansions can break the command.

sendevent_scripting.sh · BASH

12345678910111213141516171819202122232425

#!/bin/bash
# Auto-restart all FAILURE jobs matching a pattern

PATTERN="PRD_TRADING_%"

echo "Checking for failed jobs matching: $PATTERN"
FAILED_JOBS=$(autorep -J $PATTERN -s FA | awk 'NR>2 {print $1}' | grep -v '^$')

if [ -z "$FAILED_JOBS" ]; then
    echo "No failed jobs found"
    exit 0
fi

for JOB in $FAILED_JOBS; do
    echo "Restarting: $JOB"
    sendevent -E RESTART -J "$JOB"
    sleep 2   # brief pause between events to avoid overwhelming Event Processor
done

echo "Restart events sent for: $(echo $FAILED_JOBS | wc -w) jobs"

# Pattern 2: Set a global, then trigger downstream job
RECORD_COUNT=$(wc -l < /data/processed.csv)
sendevent -E SET_GLOBAL -G "TRADING_COUNT=${RECORD_COUNT}"
sendevent -E STARTJOB -J PRD_TRADING_VALIDATE_COUNT

▶ Output

Checking for failed jobs matching: PRD_TRADING_%
Restarting: PRD_TRADING_EXTRACT_DAILY
Restarting: PRD_TRADING_TRANSFORM_DAILY
Restart events sent for: 2 jobs

⚠ Add a sleep between bulk sendevent calls

When sending many sendevent calls in a loop, add a small sleep (1-2 seconds) between them. Flooding the Event Processor with hundreds of events simultaneously can cause delayed processing. A small pause keeps the event queue manageable.

📊 Production Insight

Scripting sendevent is great, but watch for race conditions.

If your script sends STARTJOB before SET_GLOBAL finishes processing, the job runs with the old global value.

For dependent operations, use autorep to verify the state before issuing the next event.

🎯 Key Takeaway

Automate recovery, but don't forget to slow down.

Sleep 2 seconds between events. Always quote your variables.

Test your script on a non-production instance first.

sendevent Event Types Deep Dive — When to Use Each

Beyond the common events, there are less frequently used but critical ones: DELETEJOB to remove jobs, RESTART to restart a failed job (respects conditions), STOP_DEMON for graceful shutdown, and SET_GLOBAL for variables. Understanding the nuances — like RESTART only works on FAILURE jobs, or that JOB_ON_ICE prevents the job from running indefinitely until explicitly released — can prevent outages.

event_types.sh · BASH

1234567891011121314151617

# RESTART - only works if job status is FAILURE or has next cycle pending
sendevent -E RESTART -J export_daily   # re-runs with original conditions

# DELETEJOB - removes job definition permanently; use with extreme care
sendevent -E DELETEJOB -J old_job

# SET_GLOBAL - sets a global variable visible to all jobs
sendevent -E SET_GLOBAL -G "ENVIRONMENT=STAGING"

# SENDSTATUS - sends an application status (rarely used, but available)
sendevent -E SENDSTATUS -J my_job -s "Data validated OK"

# STOP_DEMON - graceful shutdown of Event Processor
sendevent -E STOP_DEMON

# START_DEMON - restart Event Processor (usually via script, not sendevent)
# NOTE: There is no START_DEMON event; use the autostart mechanism

Mental Model

Mental Model: Events are signals, not commands

Think of sendevent as dropping a letter into a post box — the Event Processor reads it when it gets to it, not immediately.

Events are queued and processed asynchronously by the Event Processor
There's a small delay (milliseconds to a few seconds) between sending and the job reacting
Multiple events for the same job are processed in order, but events for different jobs may interleave
Persistent events (like STOP_DEMON) override later related events

📊 Production Insight

DELETEJOB is irreversible. Once sent, the job is gone from the database.

Always verify you have the correct JIL export before deleting.

Consider deactivating the job (via JIL) instead.

🎯 Key Takeaway

Know which events wait and which fire instantly.

FORCE_STARTJOB fires now; STARTJOB waits. JOB_ON_HOLD prevents both.

For deleting, use JIL deactivation first, then DELETEJOB only after a cooling period.

sendevent Troubleshooting and Common Failures

When sendevent 'does nothing', the culprit is almost always one of: wrong instance name, job name typo, case mismatch, or the Event Processor is down. Other issues: sending FORCE_STARTJOB to a box job (which may be running), or forgetting that JOB_ON_HOLD doesn't affect a job already running — you need KILLJOB first. This section gives you the debug flow to resolve 90% of issues in under a minute.

troubleshoot_sendevent.sh · BASH

1234567891011121314151617

# Step 1: Is the Event Processor running?
autorep -W   # returns NOSUCH? If yes, Event Processor is down

# Step 2: What is the job's current status?
autorep -q jobname | head -20

# Step 3: Check event log for recent events
tail -100 $AUTOUSER/events/events.log | grep jobname

# Step 4: Verify job name spelling and case
autorep -J "JOBNAME*" | grep -i jobname

# Step 5: Test connectivity to Event Processor host
ping autoevent_host

# Step 6: Check for multiple instances
sendevent -E PING   # sends a test event; responds with 'PONG' from Event Processor

▶ Output

AutoSys Event Processor: UP (pid 12345)
Job: daily_report
Status: FAILURE
...

🔥sendevent -E PING is your best friend

PING sends a test event to the Event Processor. If you get 'PONG' back (in the event log), you know the connection works. If not, you have a connectivity or Event Processor problem. Always run this before escalating.

📊 Production Insight

The event log is your gold mine. $AUTOUSER/events/events.log records every sendevent.

When an event 'didn't work', check the log — it often tells you exactly why (e.g., 'Invalid job name' or 'Non-existent instance').

Don't forget: events are case-sensitive, so 'daily_report' vs 'Daily_Report' are different.

🎯 Key Takeaway

When sendevent fails silently, work through the checklist in order.

Start with autorep -W, then -q, then event log.

Send PING to test connectivity. Never assume the Event Processor is running.

🗂 sendevent Event Types Comparison

Key events, their behavior, and when they are used

Event	What it does	Respects conditions?
STARTJOB	Triggers job if conditions met	Yes
FORCE_STARTJOB	Starts job immediately, bypasses conditions	No
KILLJOB	Terminates running job	N/A
JOB_ON_HOLD	Suspends job (reversible)	N/A
JOB_OFF_HOLD	Releases job from hold	Yes — runs if conditions met
JOB_ON_ICE	Strongly suspends job	N/A
JOB_OFF_ICE	Releases from ice (waits for next cycle)	Yes — waits for next occurrence
CHANGE_STATUS	Manually sets job status	N/A
SET_GLOBAL	Sets a global variable value	N/A
STOP_DEMON	Gracefully stops Event Processor	N/A

🎯 Key Takeaways

sendevent is the primary command for manually controlling AutoSys job execution and state
FORCE_STARTJOB bypasses all conditions; STARTJOB respects them — use FORCE_STARTJOB carefully in production
CHANGE_STATUS -s SUCCESS is a recovery tool to unblock dependency chains when a job was fixed manually
Always use sendevent -E STOP_DEMON to stop the Event Processor — never kill -9
When debugging, start with autorep -W, then -q, then check the event log
Add a sleep between bulk sendevent calls to avoid overwhelming the Event Processor
JOB_ON_ICE is persistent; JOB_ON_HOLD is reversible. Understand the difference before suspending jobs

⚠ Common Mistakes to Avoid

✕Using STARTJOB when you meant FORCE_STARTJOB

Symptom

Job doesn't start — no error message, user assumes it worked

Fix

Check job conditions with autorep -q. If conditions are not met, use FORCE_STARTJOB or resolve the missing condition first.

✕Using FORCE_STARTJOB without understanding what conditions it's bypassing

Symptom

Job runs immediately but later the downstream discovers missing data or out-of-order processing

Fix

Only use FORCE_STARTJOB after verifying all prerequisite jobs have completed or are irrelevant. Document exceptions in the runbook.

✕Forgetting -S instance_name in multi-instance environments

Symptom

Event appears to be ignored — actually sent to the wrong AutoSys instance

Fix

Always specify -S when more than one instance exists. Set $AUTOSYS environment variable to your default instance.

✕Using KILLJOB on a job that's in a BOX and expecting the box to continue normally

Symptom

Box job goes to FAILURE or broken status even though other box members ran successfully

Fix

When a box member is killed, the box status may change. Use autorep -b boxname to check. Consider using a box exit condition that ignores member failures.

✕Sending multiple events rapidly in a loop without a pause

Symptom

Some events are processed out of order or skipped due to Event Processor overload

Fix

Add sleep 1-2 seconds between sendevent calls in scripts. For critical sequences, verify each event's effect before sending the next.

✕Assuming JOB_ON_ICE is same as JOB_ON_HOLD

Symptom

Job never runs after JOB_OFF_ICE because it doesn't start until its next scheduled time

Fix

Remember: JOB_ON_ICE is persistent—even after release, the job won't rerun until its next cycle. Use JOB_ON_HOLD if you want to simply suspend and resume.

Interview Questions on This Topic

QWhat is the sendevent command used for in AutoSys?JuniorReveal
sendevent is the command-line tool for sending signals to the AutoSys Event Processor. It's used to manually control jobs — starting, stopping, holding, icing, killing, or changing their status — as well as setting global variables and controlling the Event Processor itself (e.g., STOP_DEMON).
QWhat is the difference between STARTJOB and FORCE_STARTJOB?JuniorReveal
STARTJOB triggers a job only if its starting conditions (date_conditions, condition attribute, file watcher) are currently satisfied. FORCE_STARTJOB bypasses all conditions and starts the job immediately regardless. Use FORCE_STARTJOB sparingly in production because it can cause out-of-order execution.
QHow do you put an AutoSys job on hold using the command line?Mid-levelReveal
Use sendevent -E JOB_ON_HOLD -J job_name to put the job on hold. To release it: sendevent -E JOB_OFF_HOLD -J job_name. The difference from JOB_ON_ICE is that JOB_OFF_HOLD allows the job to run immediately if conditions are satisfied, while JOB_OFF_ICE only allows it to run at its next scheduled time.
QWhat does CHANGE_STATUS do and when would you use it?Mid-levelReveal
CHANGE_STATUS manually changes a job's status to SUCCESS or FAILURE. Use it in recovery scenarios: when a job failed due to an infrastructure issue but the actual processing completed successfully, or when you need to block a dependency chain. Be aware that marking SUCCESS without verifying actual work can cause data corruption.
QHow do you gracefully stop the AutoSys Event Processor?Mid-levelReveal
Use sendevent -E STOP_DEMON. This sends a graceful shutdown signal, allowing the Event Processor to finish processing current events before exiting. Never use kill -9 — it can leave jobs in inconsistent states and corrupt the event queue.
QExplain how you would debug a sendevent command that appears to do nothing.SeniorReveal
Start by verifying the Event Processor is running with autorep -W. Then check the job's current status with autorep -q jobname. Look at the event log at $AUTOUSER/events/events.log for error messages. Send a PING event to test connectivity. Also confirm the correct instance with -S. Common causes: job name typo, case mismatch, wrong instance, or the job is already in a state that prevents the event (e.g., ON_HOLD prevents STARTJOB).

Frequently Asked Questions

What is the sendevent command in AutoSys?

sendevent is the AutoSys command-line tool for sending events to the Event Processor. It's used to manually start, stop, hold, ice, kill, or change the status of jobs, as well as set global variables and control the Event Processor itself.

What is the difference between STARTJOB and FORCE_STARTJOB?

STARTJOB triggers a job only if its starting conditions (date_conditions, condition attribute) are currently satisfied. FORCE_STARTJOB starts the job immediately regardless of whether conditions are met — it bypasses all condition checks.

How do I manually start an AutoSys job from the command line?

Use sendevent -E FORCE_STARTJOB -J jobname to start immediately regardless of conditions, or sendevent -E STARTJOB -J jobname to start only if conditions are met.

When would you use CHANGE_STATUS in AutoSys?

CHANGE_STATUS is a recovery tool. Use it to mark a job as SUCCESS when the actual processing completed correctly outside of AutoSys, or when an infrastructure failure caused the job to fail even though the work was done. This unblocks downstream jobs waiting on the dependency.

How do I stop the AutoSys Event Processor?

Use sendevent -E STOP_DEMON. This sends a graceful shutdown signal. Never use kill -9 — it can leave jobs in inconsistent states requiring manual cleanup before restart.

What is the difference between JOB_ON_HOLD and JOB_ON_ICE?

JOB_ON_HOLD suspends the job temporarily. When released with JOB_OFF_HOLD, the job will run immediately if its conditions are met. JOB_ON_ICE is stronger — even after JOB_OFF_ICE, the job will not run until its next scheduled occurrence (next cycle or explicit STARTJOB/FORCE_STARTJOB).

Can sendevent be used to restart a job that is currently running?

No. sendevent -E RESTART works only on jobs with status FAILURE. For a running job, you must first KILLJOB it, then use RESTART or STARTJOB.

🔥

Naren Founder & Author

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.

About Naren Get in touch

Forged with 🔥 at TheCodeForge.io — Where Developers Are Forged