The RMM job is stuck. Prove where execution stopped.
“Pending,” “failed,” “timed out,” and “success” are platform states—not complete diagnoses. Use these 24 checks to separate targeting, queue, endpoint, execution-context, script, and evidence failures before rerunning privileged automation.
1. Preserve the job
- Record the platform job ID, customer tenant, target device or group, action, requested actor, schedule, maintenance window, and expected start and finish times.
- Capture the original console state, timestamps and time zone, progress, exit code, standard output, standard error, timeout, retries, and audit events before changing the job.
- Identify the exact script, component, policy, or automation version and retain its content hash, parameters, secrets reference, interpreter, and approval record.
- Define the expected endpoint state change, acceptable evidence, stop condition, rollback, business impact, and escalation owner.
2. Separate queue from endpoint
- Confirm the endpoint is powered on, in scope, currently checking in, and enrolled under the intended customer and durable device identity.
- Compare one affected target with the entire job cohort by tenant, site, agent version, operating system, policy, network, and first-failure time.
- Check platform service health, queue depth, concurrency or rate limits, approval state, schedule expiry, maintenance windows, and cancellation or supersedence.
- Prove whether the job was created, queued, delivered, acknowledged, started, and completed as separate states rather than trusting one summary label.
3. Verify execution context
- Confirm the configured identity, privilege level, session type, interactive or non-interactive context, user profile, working directory, and 32-bit or 64-bit host.
- Check policy, application control, EDR, antivirus, script-signing, execution-policy, shell, and constrained-language evidence without disabling controls globally.
- Verify required files, modules, interpreters, environment variables, registry paths, network shares, credentials, certificates, and service dependencies.
- Test DNS, proxy, TLS, firewall, repository, package source, and destination reachability using the same execution context as the automation.
4. Inspect local evidence
- Look for the expected process, child process, scheduled task, service, lock, temporary file, transcript, event, and log entry during the recorded window.
- Capture the first local error and correlate it with platform output; distinguish delivery failure, interpreter failure, script failure, timeout, reboot, and lost-result reporting.
- Review exit-code handling, exception handling, output encoding, path quoting, parameter expansion, current directory, architecture, and assumptions about an interactive desktop.
- Measure whether the job is still doing bounded work or is blocked on input, a child process, a network call, an installer, a reboot, a file lock, or another automation.
5. Remediate safely
- Determine whether the action is idempotent and inventory any partial changes before allowing a retry, resume, replacement, or rollback.
- Correct the narrow verified dependency or script defect; change one variable at a time and preserve the actor, change, version, time, output, and result.
- Run the corrected job against one representative canary with an explicit timeout, bounded privilege, monitored output, stop condition, and rollback path.
- Do not widen targeting, disable security controls, expose credentials, or create an unbounded retry loop merely to obtain a green console state.
6. Validate and close
- Confirm a new job record with the intended target, actor, script version, parameters, start and finish times, exit code, output, and audit trail.
- Verify the expected endpoint state independently through current configuration, service, file, registry, package, process, telemetry, or business-function evidence.
- Reconcile every original target into succeeded, failed, pending, offline, excluded, cancelled, unknown, rolled back, or owned-exception states.
- Record the root cause, prevention change, monitoring improvement, residual risk, customer impact, owner, review date, and closure evidence.
Definition of a completed RMM automation job
A job is complete only when the intended endpoint state—not merely the console label—is verified for the correct tenant and durable device identity; every target is reconciled; privileged activity is attributable to an actor and script version; temporary access and artifacts are removed; and failures, exclusions, unknowns, and partial changes have owners and dated next actions.
PowerShell evidence references
When an RMM action uses PowerShell, platform output may be only one evidence source. These Microsoft references explain Windows PowerShell logging options and the automatic variables commonly used to report command and native-process results.
RMM script and job troubleshooting questions
Why does an RMM script stay pending and never run?
The endpoint may be offline or stale, the target or tenant may be wrong, the schedule may have expired, a queue or concurrency limit may be active, policy or maintenance conditions may be unmet, the platform may be degraded, or the job may have been created without being delivered. Prove queue and endpoint states separately.
Should I rerun a failed or timed-out RMM script?
Only after preserving the original evidence, checking whether the action is idempotent, inventorying partial effects, defining a safe target and stop condition, and testing one representative endpoint. A blind rerun can repeat privileged changes or create conflicting state.
What proves an RMM automation job succeeded?
Capture the intended target, actor, script version or hash, start and finish times, exit code, output and errors, the expected endpoint state change, current telemetry, audit evidence, and reconciliation of every targeted endpoint.