> For the complete documentation index, see [llms.txt](https://doc.engenius.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.engenius.ai/bmc-user-guide/monitoring/system-logs-and-events.md).

# System Logs and Events

While real-time sensor data is great for spotting current issues, system logs provide a historical record of everything that has happened on the server. When you're investigating a past failure or an intermittent problem, the logs are the first place you should look.

This chapter teaches you how to read the different types of logs the BMC records, from high-level system events to low-level boot codes.

## **Viewing and filtering event logs**

The **Event Log** is your primary source for understanding the server's health history. It captures hardware-related alerts, status changes, and errors, each with a timestamp and a severity level.

To view the event logs:

1. In the sidebar menu, navigate to **Logs** > **Event logs**.<br>

   <figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXd_u72qV70slmjAZZoeiLwZhWafopZuWm62-EfL-dfT3IcU2Fpt7kr9cpJAMGIEM9cdhLtON--axLkQZLTfxi_G114S83LkXtXhr5O7x1AXRFGxy5nukgJnJUBscgnfx0Kqymf7Fg?key=UlDoHTEZLTRXe-KURf91Rw" alt=""><figcaption></figcaption></figure>
2. You will see a table of all recorded events.

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXeECWjYdnQeNf_YQgF4KHzmHGjN6xdl8SqKaFo8DhlML_VJBH_LQeTgPY4YOLs4a-tc-xN_bEgY7EIrQP9Lmk-wpptYCC-WotxZkQ9SXWMlTKKBB42px2EtCE4cFXN1Wj4jrZE4?key=UlDoHTEZLTRXe-KURf91Rw" alt=""><figcaption></figcaption></figure>

Each log entry includes:

* **Severity**: The importance of the event (e.g., `Critical`, `Warning`, `OK`).
* **Date**: The UTC timestamp when the event occurred.
* **Description**: A brief explanation of the event.

{% hint style="info" %}
**Pro Tip: How to approach the event log**

When troubleshooting, filter the log to show only `Critical` and `Warning` events first. This helps you cut through the noise of normal operational messages (`OK`) and focus on the actual problems. You can also filter by date to narrow down events that occurred around the time of a reported failure.
{% endhint %}

To export the logs for sharing or offline analysis, click the **Export all** button. You can typically export them in formats like JSON, which is useful for sending to support teams.<br>

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXdfgBMKmDn52sGblF-MmWu3BNbUztDL9CnUooVPQ24ds_9KBV9yvsq1Rx43e9jxFFw1YycTzQiQF-4MHom3m9jQVNDBBadzk3D5lO0eBaeUJLmGWgAY4henxwzv0J0cMEqqEpaMZQ?key=UlDoHTEZLTRXe-KURf91Rw" alt=""><figcaption></figcaption></figure>

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXesC3lAGXYmBOiepP-0RfnFLqoqvbLbY48J2KfzInPsBvMS68_w2yZJ73AA5rELur1P-sl8Oga6TptP6yIw8s1SAXYKkb8X-JGjczDnoA5V1LNV6kv6WrO_qRQyeraEyVhrOlDx?key=UlDoHTEZLTRXe-KURf91Rw" alt=""><figcaption></figcaption></figure>

**Field Reference**

<table><thead><tr><th width="118.54547119140625">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>ID</strong></td><td>A unique identifier for each log entry.</td></tr><tr><td><strong>Severity</strong></td><td>The importance of the event (e.g., <code>Critical</code>, <code>Warning</code>, <code>OK</code>).</td></tr><tr><td><strong>Date</strong></td><td>The UTC timestamp when the event occurred.</td></tr><tr><td><strong>Description</strong></td><td>A brief explanation of the event that was triggered.</td></tr><tr><td><strong>Status</strong></td><td>Allows you to manually toggle the status to "Resolved" once the issue has been addressed.</td></tr></tbody></table>

## **Analyzing POST code logs for boot issues**

If a server fails to boot and you can't even get to the OS, the **POST (Power-On Self-Test) code log** is an invaluable tool. It records the sequence of hardware initialization codes generated by the BIOS during startup.

Navigate to **Logs** > **POST code logs** to view these records.

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXeDIRh--16BT7dyJmSqMQiNjWfkUGrCW_9GPJ69E7gMQG439HypaYtYGlvTQWqHggd2aNa7q0M5rrUogxMJRgPX_e2fjsJPt2tIWzjjq5GfrzRpW0HVRAFgboCAmxlcz3dTmpUyrQ?key=UlDoHTEZLTRXe-KURf91Rw" alt=""><figcaption></figcaption></figure>

If the server hangs during boot, the last POST code recorded in this log can often tell you exactly which hardware component or initialization step is causing the problem.

**Field Reference**

<table><thead><tr><th width="169.2557373046875">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Created</strong></td><td>The timestamp when the POST code entry was recorded.</td></tr><tr><td><strong>Time Stamp offset</strong></td><td>The time offset, in seconds, relative to the start of the boot process.</td></tr><tr><td><strong>Boot count</strong></td><td>The boot cycle number associated with this code.</td></tr><tr><td><strong>POST code</strong></td><td>The hexadecimal value representing a specific hardware initialization checkpoint.</td></tr></tbody></table>

## **Generating and downloading system dumps**

For complex, low-level issues, a support engineer might ask you for a "system dump." This is a snapshot of the BMC's internal state and memory, which can be used for deep-level debugging.

To generate a system dump:

1. Navigate to **Logs** > **Dumps**.
2. Select the dump type (usually **BMC dump**).
3. Click **Initiate dump**.

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXeFNTd6OqK8l_P37isCmYQD0SLaMw343o_vb6d-9RmRXcktTqfwqnuH0B42TsqdGihHzzTBGNGsUd_K5mF1PF8pmoPVcmVQu0ksk43OuGNs86qOsZtSma7-0lBS0_gOYT-0hH9i4A?key=UlDoHTEZLTRXe-KURf91Rw" alt=""><figcaption></figcaption></figure>

The process can take a few minutes. Once complete, the dump file will appear in the list, and you can download it to your local machine.

**Field Reference**

<table><thead><tr><th width="134.05322265625">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Date and time</strong></td><td>The timestamp when the dump was completed.</td></tr><tr><td><strong>Dump type</strong></td><td>The type of dump collected (e.g., <code>BMC Dump Entry</code>).</td></tr><tr><td><strong>ID</strong></td><td>A unique identifier for the dump file.</td></tr><tr><td><strong>Size</strong></td><td>The file size of the generated dump.</td></tr></tbody></table>

## **Reviewing video logs of system events**

Some platforms are configured to automatically record a short video clip of the KVM console output when a critical event occurs (like a system reset or a crash). This can help you see exactly what was on the screen at the moment of failure.

Navigate to **Logs** > **Video Log** to see a list of available recordings. You can download and play these video files (`video.dat`) to aid your diagnosis.

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXdXMmExOA7rwghfGU45KUVHtdeX0OoWqUuECe74axGFvtKL0zcNPzi3WC88tDcj-tUFjyHq6oknZl7WZ39frNuvDlekHPOU5iI3DGvarbrVCZaCdwriLLN4lZImVlfs8Kp9cZks0Q?key=UlDoHTEZLTRXe-KURf91Rw" alt=""><figcaption></figcaption></figure>

## **Capturing Blue Screen of Death (BSOD) images**

If the host operating system crashes (for example, showing a "Blue Screen of Death" on Windows), the BMC can automatically capture a screenshot of the failure screen. This is extremely useful because it preserves the error codes and messages displayed on the screen, which might otherwise be lost after a reboot.<br>

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXeuG7tCUPXhcN5haSp3bKtjD3bxSLUw2OKLzGXaxEp5TtAyCt4GxoF2kz0dgY8PRz0Ek4XOIxrO1d15I34ALJh6_593sHeglnkzThB4Oxd7A5EtajJWWgnxmvZXaKt_Yu-gFT8Ebg?key=UlDoHTEZLTRXe-KURf91Rw" alt=""><figcaption></figcaption></figure>

To manage a captured BSOD image:

1. Navigate to **Settings** > **BSOD**.
2. The page will display the last captured screen.
3. You have three options:
   * **Trigger**: Manually initiates a capture of the BSOD screen if the host is in a critical stop state.
   * **Download**: Saves the currently displayed BSOD image to your local machine for analysis.
   * **Delete**: Clears the stored image from the BMC.

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXdCY5uq7Lk75llQW9aiXLgWY--Kpb-MspYvPd7w4di3Cl3_Qo_VhwDcFKJcHSTCy_VCE8S4uLmhhVS7D-ZmfAMIeEg46RloZOUTunWpxsHJXUgZKrsfvzNd6WzOd70RlG8FD2YlFQ?key=UlDoHTEZLTRXe-KURf91Rw" alt=""><figcaption></figcaption></figure>

{% hint style="success" %}
**Best Practice: Don't reboot too quickly**

After a server crashes, resist the urge to immediately reboot it. Log into the BMC first and check the BSOD page. Capturing that screenshot can be the key to understanding the root cause of the crash.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://doc.engenius.ai/bmc-user-guide/monitoring/system-logs-and-events.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.