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
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.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
Related
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.