An error that does not stop the script and may allow later commands to continue running. PowerShell cmdlets often emit these when processing multiple objects and only some items fail. They can be useful for bulk work, but they also create risk if teams do not inspect results carefully.
What a non-terminating error means in practice
A non-terminating error is a failure that does not halt the current script or pipeline. In PowerShell, that means later commands may still run, so the error can be easy to miss if the output is noisy, automated, or only partially reviewed. The key point is that execution and correctness are not the same thing.
This makes the term operational rather than purely descriptive. It is often used in bulk operations where some objects succeed and others fail, but it demands deliberate checking of error records and results. Without that review, teams can assume a task completed cleanly when only part of it did.
Where non-terminating errors appear
PowerShell cmdlets commonly emit non-terminating errors when they process many targets at once, such as files, users, hosts, or records. The cmdlet continues because the failure may apply to one item rather than the whole batch. That design is useful for scale, but it also means a single failed item can be buried inside a mostly successful run.
The distinction matters because many automation patterns treat “command returned” as success. With non-terminating errors, a script can continue, write logs, and even produce partial output while still leaving important items unchanged. In other words, the command succeeded at execution but not necessarily at the intended business outcome.
Why it is easy to overlook
Non-terminating errors are often overlooked when operators rely on console output alone. The message may be easy to scroll past, or buried among many benign warnings. In unattended jobs, the risk is higher because the script can finish with a normal exit path even though some actions failed.
The practical hazard is silent partial failure. A workflow that updates permissions, removes records, or reconciles state may leave behind exceptions that are not obvious until a later audit, incident, or user complaint. That is why these errors should be treated as signals to inspect both the error stream and the resulting state, not just the final return code.
How to interpret them safely
Non-terminating errors should be read as “the task continued, but one or more items did not complete as intended.” They are not automatically harmless, and they are not automatically fatal. Their meaning depends on the command, the object set, and whether the failed items are optional or critical to the operation.
For practitioners, the right mental model is partial success with uncertain completeness. That means the real question is not whether the script kept running, but whether the final state matches the intended change set. If the answer is no, the error was operationally meaningful even if execution did not stop.
Risk and Threat Considerations
Non-terminating errors create exposure when teams assume successful execution means successful enforcement. In administrative scripts, that can leave access, configuration, or cleanup actions only partly applied, which is especially dangerous when later steps depend on the earlier ones having worked.
Failure mechanism: A command fails on one or more objects, emits an error, and then continues running, so the script can produce a normal-looking completion path while leaving inconsistent state behind.
Impact: Partial failures can hide broken remediation, incomplete deprovisioning, missed configuration changes, or stale records that only surface later during review or incident response.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Non-terminating errors require review of logs and error records to detect partial failure. |
| Recommendation — Review error output and audit records to confirm every intended object actually changed. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | These errors are only useful if operators consistently capture and inspect execution evidence. |
| Recommendation — Centralise command logs and investigate partial-failure patterns in administrative automation. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | Partial command failure is a detectable operational event that should be monitored. |
| Recommendation — Monitor automation results for anomalies that indicate partial success or hidden failure. | ||
Practitioner Guidance
What to watch for: Treat non-terminating errors as a review trigger, not as background noise. For bulk jobs, validate the error stream and the affected objects separately from the overall script status, because the outcome may be only partially successful.
Practitioner takeaway: If the change matters, verify the end state, not just that the script finished.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org