# Reading Logs
**Audience:** IT admins who need to find, read, and use Keeper Privilege Manager logs for troubleshooting and compliance.
***
## Overview
Keeper Privilege Manager uses **centralized logging**: the main service and plugins send log messages to a **Logger** component (e.g. KeeperLogger plugin), which writes them to **log files** and optionally to system logs or an HTTP endpoint. Understanding where logs are and how they’re formatted helps you troubleshoot policy denials, job failures, and registration or plugin issues.
## **Log File Naming Convention - Platform Agnostic**
The active log file is `KeeperLogger.log`. On rotation — either at midnight or when the size limit is reached — it is renamed to `KeeperLogger_YYYYMMDD.log` or `KeeperLogger_YYYYMMDD_HHMMSS.log`. Files are retained based on the `logRetentionDays` setting (default: 15 days), after which the oldest rotated files are deleted automatically. The active file is never deleted by the retention policy.
* **File name pattern:** Often date-based, e.g. `KeeperLoggerYYYYMMDD.log` (one file per day).
## Where the Log File Is
The default log file paths listed below reflect the default installation layout. However, the exact location of log files on any given deployment depends on how the KeeperLogger plugin has been configured. If your organization customized the installation directory, deployed to a non-standard path, or explicitly set a log output location during setup, the log files may be in a different location than the defaults shown. Before assuming a path, verify the active configuration directly.
{% hint style="danger" %}
Log file locations for any given deployment may be configured in the KeeperLogger plugin configuration.
{% endhint %}
The following settings in the KeeperLogger plugin configuration control where logs are written and how they are managed:
* `log.file.path` — The directory where log files are written. This value may use path variables such as `{approot}` which resolves to the installation root at runtime, making the setting portable across machines regardless of where KEPM is installed.
* `log.retention.days` — How many days of rotated log files to retain before the oldest are deleted automatically.
* `log.rotation.size_mb` — The maximum size a log file can reach before it is rotated and a new file is started.
{% hint style="info" %}
If you’re unsure, search the install directory for `*.log` or look in the Logger plugin folder for a `Log` subdirectory.
{% endhint %}
### **Default Log File Paths**
Log file **location** is configurable. Typical defaults:
* **Under the Logger plugin directory:** e.g. `Plugins/Logger/bin/Release/net8.0/Log/` or a similar path under the application root. The exact path can be in the Logger plugin config or in application settings.
* **File name pattern:** Often date-based, e.g. `KeeperLoggerYYYYMMDD.log` (one file per day).
* **Application root:**
* Linux `/Library/Keeper/sbin/Plugins/bin/KeeperLogger/Log`
* macOS `/opt/keeper/sbin/Plugins/bin/KeeperLogger/Log`
* Window `C:\Program Files\KeeperPrivilegeManager`;
***
### Log Levels
Logs are emitted at different **levels**. Common levels (from least to most severe):
* **Debug** — Detailed diagnostic information (noisy; use for deep troubleshooting).
* **Information** — Normal operations (e.g. job started, policy evaluated).
* **Warning** — Recoverable or unexpected conditions (e.g. optional step failed, fallback used).
* **Error** — Failures (e.g. task failed, plugin crash).
* **Critical** — Severe failures that may affect service stability.
The **minimum level** written to the log file (or to the Logger) is usually configurable (e.g. in plugin settings or appsettings). In production, **Warning** or **Information** is typical; for troubleshooting, **Debug** gives the most detail. Error and Critical are often always written even when the minimum level is higher.
***
### Log Format and Structure
Log entries are usually **structured** (e.g. JSON or a consistent text format) so you can search and parse them. A typical entry might include:
* **Timestamp** — When the event occurred (often UTC or local).
* **Level** — Debug, Information, Warning, Error, Critical.
* **Component / category** — Which part of the system logged (e.g. KeeperPolicy, JobService, KeeperLogger).
* **Message or event name** — Short description or event code (e.g. POLICY\_EVALUATION, JOB\_TRIGGERED, AGENT\_REGISTERED).
* **Context** — Optional key-value data: correlation id, job id, policy id, user, path, exit code, etc.
**Example (conceptual):**
```
2025-02-23T14:30:00Z [Information] [KeeperPolicy] POLICY_EVALUATION PolicyId=policy-123 Result=Deny User=DOMAIN\jane Application=C:\Windows\System32\mmc.exe
```
Or in a JSON-style line:
```
{"timestamp":"2025-02-23T14:30:00Z","level":"Information","component":"KeeperPolicy","event":"POLICY_EVALUATION","policyId":"policy-123","result":"Deny","user":"DOMAIN\\jane","application":"C:\\Windows\\System32\\mmc.exe"}
```
Use **grep**, **findstr**, or a log viewer to search by level, component, event name, policy id, user, or correlation id. Correlation ids help you follow a single request across multiple log lines.
***
### What to Look for When Troubleshooting
* **Policy denials:** Search for the policy id, event type (e.g. PrivilegeElevation), and “Deny” or “ApplicablePolicyIds: 0”. Check which policies were evaluated and why none allowed the request (e.g. filters didn’t match, or admin fallback denied). See [Architecture](/keeperpam/privileged-access-manager/getting-started/architecture.md).
* **Job failures:** Search for the job id and “JOB\_EXECUTION”, “Task”, “exit code”, or “Failed”. Check which task failed and the exit code or error message.
* **Registration:** Search for “AGENT\_REGISTER”, “AGENT\_REGISTERED”, or “REGISTER\_ERROR” to see whether registration succeeded or why it failed.
* **Plugin startup:** Search for plugin name and “started”, “failed”, or “crashed” to see if a plugin failed to start or exited unexpectedly.
* **Errors and critical:** Filter by level Error and Critical to see all failures in a time range.
***
### Rotation and Retention
* **Rotation:** Logs may rotate by **date** (new file per day) or by **size** (new file when current file reaches a limit in MB). Old files are kept according to **retention** (e.g. 30 days). Configurable via Logger plugin settings.
* **Disk space:** Ensure the log directory has enough space; adjust retention or size limits if logs grow too large.
***
### System Logs (fallback)
When the Logger plugin is unavailable or for critical errors, the **main service** may write to **system logs** (Windows Event Log, systemd journal, or macOS unified logging). Check Event Viewer (Windows), `journalctl -u keeper-privilege-manager` (Linux), or Console.app (macOS) for Keeper Privilege Manager or the service name. These are a fallback; the primary place for detailed, structured logs is the Logger log file.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.keeper.io/keeperpam/endpoint-privilege-manager/user-guides/reading-logs.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.