System Audit
System Audit checks your configuration and reports what is wrong with it. Over time, normal editing leaves behind loose ends - a route that still points at a deleted user, a voice menu option with no destination, an outbound route whose trunk was removed. These rarely announce themselves. They surface when a caller hits them, which is the worst moment to find out. System Audit finds them in one pass across every tenant.
Why you would want it
Most configuration mistakes are invisible from the screen you made them on. Deleting a user does not go back and correct the four inbound routes that pointed at them; those routes keep their stored reference, and the call fails at the moment someone dials in. Nothing warns you, because from the route’s point of view nothing changed.
The audit closes that gap by checking every stored reference against what actually exists, and by checking configurations that are complete on their own but wrong in combination.
Severity: what to fix first
A large system can carry hundreds of findings, most of them harmless. Severity says which ones cannot wait, and it is independent of the type of finding - a reference problem and a routing problem can both be critical or both be minor.
- Critical - the call does not complete. A tenant with no emergency route, or an outbound route that names no trunk. Fix these before anything else.
- Error - calls connect, but something is wrong or is not being delivered correctly. A route pointing at a voice menu that no longer exists, or a tenant with no emergency caller ID.
- Advisory - the configuration is incomplete, but nothing misbehaves. A user with no email address recorded.
Findings are sorted with critical first, whatever else you have the screen filtered to, so the ones that matter are always at the top.
Critical findings on the Dashboard
When the most recent audit found anything critical, the Dashboard shows a red bar naming the count, with the date of that check and a Review link. Following it opens System Audit already filtered to those findings, so you see exactly the ones the count refers to rather than the whole list.
When the last run found nothing critical, the Dashboard says so in one quiet line with the date. That line matters as much as the alert: it tells you the check ran and came back clean, rather than leaving you unsure whether it ran at all.
The bar reflects the last run, not live state. If you change configuration after a run, the Dashboard keeps reporting the older result until the audit runs again.
When the audit runs
- On demand - open the screen and click Run Audit.
- After an upgrade - an installation runs the audit when it finishes and records the result in the installation log. Findings reported there are existing configuration problems, not installation errors; the log says so explicitly, and the installation is reported as successful separately.
There is no scheduled run. If you want the Dashboard figure to stay current between upgrades, run the audit yourself after significant changes.
What it checks
Emergency calling
Emergency calling is checked separately from ordinary routing because a fault here is not recoverable at the moment it matters.
- No emergency route - the tenant has no emergency route at all, so a caller dialling an emergency number reaches nothing. Critical.
- Emergency route names no trunk - reported only when the tenant also has no ordinary outbound route for the call to fall back to. Critical.
- No emergency caller ID - the answering centre has no number to call back on. Satisfied by a value on the tenant or on any extension. Error.
- No emergency location - no address is available for the call. Error.
- Nobody notified on site - no phone or email is set to alert someone on the premises when an emergency call is placed. Error.
Routing
- Outbound route names no trunk - the call has nowhere to go and fails. Unlike an emergency route, an ordinary one has nothing to fall back to. Critical.
- Inbound route with no fallback destination - a caller who does nothing reaches nothing.
- Time-based routing with no schedule covering all hours - a call arriving outside every configured period is unhandled.
References
Objects that point at objects which no longer exist:
- Inbound routes naming a missing mailbox, voice menu, hunt group, queue, schedule or mode
- Voice menu options with no destination
- Hunt group steps naming a phone that is gone - each phone in a step is checked separately
- Feature codes naming a missing script or destination
- User extension scripts that are no longer present
- Dangling includes - a dialplan section that includes another section which has no content behind it, so the include resolves to nothing
Email addresses
- Users with no email address recorded - Advisory
- Addresses that are not valid - Error
- The same address used by more than one user - Advisory
A missing address also prevents Secure Password Mode from being turned on, because a user who cannot receive a password reset would be locked out. That check reports it as blocking in its own screen, which is why the same finding is only advisory here.
Reading the results
Navigate to General Settings & Tools > Tools > System Audit. Each row shows:
- Severity - Critical, Error or Advisory
- Organization - which tenant the finding belongs to
- Type - reference, routing, or the specific email check
- Object Type - what kind of thing the finding is about: inbound route, menu, hunt group, schedule, office mode, feature code, user extension, dialing plan, emergency route, outbound route, or the organization itself
- Name - the specific object. Tenant-wide findings such as a missing emergency location name the organization, since there is no single object to point at.
- Description - what is wrong, in full
Click the edit icon on a row to open the object and correct it. If the object belongs to a tenant you are not currently working in, the screen tells you to switch tenant first, then click edit again. For findings that have no single form to open - a tenant-wide setting, or an outbound route - the screen names the menu to go to and the object to look for instead.
Filtering
- Severity - All, Critical, Error, Advisory
- Organization - one tenant, or all
- Type - reference, routing, or one of the email checks
- Object Type - narrow to one kind of object
- Name - matches any part of the object name
The severity filter is the one to reach for first on a system with a long list. Setting it to Critical answers “is anything actually broken right now”.
From the command line
The same audit is available as a script on the server, which is useful for checking a system without signing in, or from your own monitoring:
cd /usr/libexec/webmin/asterisk && perl check.plIt exits 2 if anything critical was found, 1 if there are findings but none critical, and 0 if there are none, so it can be used directly as a monitoring check. Add --json for machine-readable output, or --store to record the run so the Dashboard picks it up.
Audit history
Every run is recorded with its timestamp, the counts it found, and who ran it. Runs are kept indefinitely; nothing removes them automatically.
Best practices
- Fix critical findings the day you see them. They are, by definition, calls that do not complete.
- Run the audit after bulk changes - imports, tenant migrations, or anything that deleted objects other configuration might still reference.
- Run it before and after a platform update, so you can tell an existing problem from a new one.
- Do not treat a long advisory list as urgent. Hundreds of users with no email address is untidy, not broken. Filter it out and work on the top of the list.
- Use the Change Log alongside the results to see when a problem was introduced and by whom.
Related documentation
- Change Log - see who changed what and when
- Managing Your PBX - where the audit fits in day-to-day operations
- Data Sync - confirm configuration reached all servers