Audit log, device log, and reports

Logs and reports help you understand what happened in a Qarvix mesh: who changed settings, which devices connected, when configuration was applied, and what you can show to operations, support, or a manager.

Without logs, remote access turns into a set of manual actions. With logs, you can see who did what and exactly when a problem started.

In short

• The audit log shows user and administrator actions.
• The device log shows agent, connection, and configuration-apply events.
• Reports help record site state and service work.
• Events matter for incident review and contractor oversight.
• For production meshes, it's worth checking logs regularly, not only after an outage.

Audit log

The audit log answers the question: who changed the state of the system.

It's important to see events like:

• user login;
• user invitation;
• role change;
• organization creation;
• network creation;
• adding a device or client;
• generating a connection token;
• ACL change;
• turning on a route to a LAN subnet;
• turning on an exit node or peer mesh;
• creating an API token;
• revoking access.

The audit log matters especially for service companies. It helps confirm who did the work, when access changed, and what actions preceded a client's request.

Device log

The device log shows what happened with a specific router, agent, or network member.

Useful events:

• device connected;
• device went offline;
• agent received configuration;
• configuration applied;
• WireGuard came up or lost connectivity;
• heartbeat stopped arriving;
• device data changed;
• agent version updated;
• an error applying a route occurred;
• device sent diagnostic data.

The device log helps separate an access problem from a configuration problem. For example, if the agent receives configuration but the LAN is unreachable, it's likely worth looking at routing, firewall, or ACL.

Connection events

For operations, it's not just errors that matter, but regular online/offline events too.

Check:

• when the device was last online;
• how often it loses connectivity;
• whether disconnects line up with mobile carrier issues;
• whether a fresh WireGuard handshake is visible;
• whether configuration was applied after a route change;
• whether an old WSS session got replaced by a new one.

If a device connects over a regular SIM card, brief connectivity drops can be related to mobile network quality. The log helps tell these apart from configuration errors.

Reports

Reports are needed for regular operations and for talking with non-technical project stakeholders.

Typical questions a report should answer:

• which sites are connected;
• which devices are online;
• which devices haven't been in touch for a while;
• which agent versions are in use;
• which LAN subnets are open over the tunnel;
• who has access to which sites;
• what access changes happened over a period;
• what events happened before an incident;
• what work the service team did.

For a manager, a report shows not just "the VPN works," but manageability: sites are visible, access is controlled, actions are reviewable.

Reports for the service team

The service team usually needs:

• a list of sites and statuses;
• a list of devices with VPN IPs;
• problem devices;
• recent events;
• routes to LANs;
• available device APIs;
• users with access to the site;
• changes over a period.

A report like this helps plan work and review requests faster.

Reports for a client or manager

A client or manager usually doesn't need WireGuard and WSS details.

It's more useful to show:

• how many sites are connected;
• which sites are reachable;
• where connectivity issues exist;
• what work was done;
• who had access;
• what changes were made;
• what risks or open questions remain.

Wording should be clear without deep networking knowledge.

Incident review

During an incident, it's important to gather the chain of events.

Order:

1. Identify the site, network, and device.
2. Check the audit log for the period before the incident.
3. Look at changes to ACL, routes, users, and tokens.
4. Open the device log.
5. Check online/offline status, heartbeat, and the WireGuard handshake.
6. Compare the timing of changes with the timing of the complaint.
7. Check reports or exports for the period.
8. Record the conclusion and next steps.

This approach helps you look at the sequence of events instead of arguing about "who changed what."

Contractor oversight

If a contractor gets access to a site, logs should help you check:

• when access was granted;
• who granted it;
• which network or subnet;
• what actions were taken;
• when the work ended;
• whether access was revoked;
• whether routes or ACL changed.

This matters especially if the contractor is working with cameras, PLCs, POS terminals, or device APIs.

What to record in reports

A minimal set for an operational report:

The report format can be adapted to the client: a short management version and a detailed technical version.

Common situations

A user says they "didn't change anything"

Check the audit log: role, ACL, route, token, and network changes.

A device suddenly went offline

Check the device log, the time of the last heartbeat, the WireGuard handshake, and mobile network or firewall events.

After a route change, the LAN is unreachable

Check whether the agent applied the configuration, whether the route exists on the network, whether ACL allows access, and whether there's a subnet conflict.

A contractor finished the work

Check that their access was revoked, temporary tokens aren't active, no unnecessary API tokens were created, and the changes are reflected in the log.

You need to confirm the work that was done

Generate a report for the site: period, connected devices, events, access changes, and current status.

Practical recommendations

• Check logs after every access change.
• Save reports for regular periods on production meshes.
• Don't delete events that might be needed for an investigation.
• Keep separate reports for engineers and managers.
• Record who's responsible for each site.
• Use clear network and device names so reports read without needing to be decoded.
• After a contractor's work, review the audit and revoke access.

Checklist

• The audit log shows changes to users, roles, and routes.
• The device log shows connection and configuration-apply events.
• A status report can be generated for sites.
• Offline devices are visible in reports.
• Agent and firmware versions are visible in reports, if available.
• Contractor access is reviewed after the work is done.
• ACL and subnet route changes are recorded.
• The sequence of events can be reconstructed for an incident.

Related sections

• Users, roles, and SSO - who gets access and how to revoke it.
• Devices and VPN addresses - which device data is useful for reports.
• Networks, routes, and ACL - which route and rule changes to track.
• Diagnostics and common issues - how to use logs when tracking down causes.