Operational logs¶

Open Logs for read-only application and appliance diagnostics. Use the page to narrow an incident by time, severity, source, and message before moving to a service-specific verification step.

Interface overview¶

This verified appliance view provides visual orientation before you begin.

Figure: Logs in the verified clean-appliance desktop state.

Investigate a problem¶

1. Set a narrow time window around the observed failure.
2. Filter by severity and the affected Atlaso component.
3. Correlate task identifiers with Tasks and operator actions with the Audit log.
4. Record the smallest sanitized excerpt that explains the failure.

The UI intentionally avoids presenting credentials and secret-bearing command lines. If a log entry appears to contain sensitive data, do not publish it; follow the private process in the repository security policy.

IP addresses, MAC addresses, hostnames, and account names are not sensitive by themselves in Atlaso. Passwords, tokens, authenticated URLs, session material, private keys, password hashes, credential verifiers, and other secret-bearing data remain sensitive. Content-integrity hashes of non-secret material and one-way change-detection hashes of encrypted-at-rest ciphertext do not. Review the complete excerpt before sharing it because authentication or cryptographic context can make an otherwise ordinary identifier sensitive. This classification does not make authenticated logs public or override site handling policy.

Next steps¶

Logs are evidence, not an enforcement surface. Correct desired state in the owning service page and submit it through Appliance Apply. For local recovery when the web UI is unavailable, use the local appliance console.

Additional verified states¶

These captures show responsive layouts and useful operational states referenced by this page.

Logs¶

Figure: Logs in the verified clean-appliance responsive state.