{% extends "documentation/base.html" %} {% block doc_content %}
Configure override rules to automatically handle known issues, expected warnings, and special backup scenarios.
Overrides are rules that modify how BackupChecks interprets backup job results. They allow you to handle known issues or expected warnings without manually reviewing every occurrence.
Common use cases:
To manage overrides:
Overrides can be created at two levels:
Applies to all jobs matching specific criteria:
Global overrides are useful for handling issues that affect multiple jobs across multiple customers.
Applies to a specific job or specific object within a job:
Object-level overrides are more precise and are checked before global overrides.
In addition to level (global or object), overrides can match specific conditions:
Match only runs with a specific status:
Most overrides match "Warning" or "Failed" to handle known issues with those statuses.
Match based on error or warning message content:
| Match Type | Description | Example |
|---|---|---|
| Contains | Error message contains the specified text (case-insensitive) | "Retry" matches "Backup retry succeeded" |
| Exact | Error message exactly matches the specified text | "Retry succeeded" only matches that exact phrase |
| Starts with | Error message starts with the specified text | "Retry" matches "Retry succeeded" but not "Backup retry" |
| Ends with | Error message ends with the specified text | "succeeded" matches "Retry succeeded" |
Leave the error text field blank to match any error message (or no error message).
The primary action for overrides is Treat as success (enabled by default):
This allows you to visually differentiate between:
Overrides can be time-limited using the From and Until fields:
The fastest way to create an override is from the run you are reviewing. After clicking Mark as Success in the Run Checks modal, a follow-up dialog "Apply override for future runs?" appears with:
Broader overrides created this way are audit-logged with their scope, duration, and source run. This path covers most day-to-day use cases without ever opening the Overrides page.
To create a new override:
The "Existing overrides" table shows all configured overrides with the following columns:
Disabling is useful when you want to temporarily stop an override without deleting it (e.g., to test if an issue is resolved).
When a job run is evaluated, overrides are checked in the following order:
The first matching active override is applied. If multiple overrides match, only the most specific one takes effect.
A Veeam backup job frequently shows warnings like "Backup retry succeeded". This is acceptable - the job ultimately succeeded.
Solution: Create an object-level override:
A customer is performing server upgrades next week. Backup failures during May 15-17 are expected.
Solution: Create a time-limited override:
After May 18, the override automatically expires and failures will appear normally.
One VM in a multi-VM backup job consistently fails with "Snapshot timeout". A ticket has been created with the customer.
Solution: Create an object-specific override:
Other VMs in the same job will still show failures normally.
All NAKIVO replication jobs show harmless warnings about "Network latency detected". This is expected for remote sites.
Solution: Create a global override:
If an override doesn't appear to affect a job run:
If an override is affecting more jobs than intended:
Only one override is applied per run (the most specific match). If you have both global and object-level overrides that match: