Overview

An event is a durable record that something happened to a resource, at a time, at a severity, attributed to a user. Where Jobs tells you whether your action finished, Events tells you the history.
Navigation: Monitor → Events. Titled Events, subtitled “Infrastructure events across all resources”.

The 500-record window — read this first

Events loads one page of up to 500 recent records for your chosen date range, then does everything else in the browser. The consequences are not obvious:
  • Search only searches those 500 records. A machine deleted last month won’t be found by typing its name, however specific the term.
  • The level filter only filters those 500. Filtering to Error shows errors within the window, not all errors.
  • The stat cards describe the window, not your history. Total is at most 500.
The date range is the only control the platform actually applies. To look further back, move the date range — don’t rely on search.
Investigating something specific? Set a narrow date range around the time you care about first. A tight window makes it far more likely the 500 records actually contain what you’re looking for, where a month-wide range will be truncated well before it reaches the event you want.

Columns

Missing values show .

Levels

The dashboard’s health banner is driven by the Error and Warn counts — see Dashboard.

Toolbar

Grouping

Group by turns the flat list into collapsible sections, collapsed by default, each headed with its count.
Grouping applies to the current page, not the whole result set. So group counts add up to your page size rather than to the total, and a group’s header count is not “how many of these exist”. Use grouping to organise what’s on screen, not to count.

Events versus the audit log

Both record history, from different angles:

Worked example: why did a machine restart overnight?

1

Set a narrow date range

Start and end covering just the night in question. This keeps the 500-record window focused on the period that matters.
2

Group by Event type

Related events cluster, so a restart and whatever preceded it become easy to see together.
3

Check Warn and Error first

Filter to Error, then Warn. A restart with no error before it is usually deliberate; one following an error usually isn’t.
4

Read the User column

A username means a person or an automation did it. Empty usually means the platform did.
5

Cross-check against Jobs

If a user triggered it, Jobs shows the operation and whether it succeeded. Widen the job time window to cover the same night.
If the window truncated before reaching the event you want, you’ll see the list start abruptly rather than an explicit warning. Narrow the date range and look again — that’s the signal you’ve hit the 500 ceiling.

Empty and error states

Jobs

Live operations, fully server-side filtered.

Audit Log

The same history organised around people.

Dashboard

The health banner and Recent Activity summarise this screen.