Events Explorer
The Events page (Dashboard > Events) is the raw telemetry view: every navigation, credential attempt, and authentication flow the browser extension fleet reports, whether or not anything suspicious happened. Where the Alerts page shows the needles, Events shows the haystack — and having the haystack is what makes investigations, baselining, and attack-surface discovery possible.
Use it to answer questions like "which sites are employees actually logging into?", "did anyone submit credentials to this domain last week?", or "how much of our login traffic uses MFA?".
How it works
Enrolled extensions batch and send telemetry events continuously. Events are stored in the analytics database and surfaced here in three streams:
- Navigation — page visits: which origin was loaded, how the navigation happened, and where the user came from.
- Credential Attempts — login form submissions: which fields were present, whether the password was found in known breach data, and whether policy blocked or warned the submission.
- Auth Flow — authentication flows: the flow type, the identity provider involved, and whether MFA was used.
Events are privacy-preserving by design. Passwords never leave the endpoint — credential events carry only one-way fingerprint metadata (for example, "this password is known-breached"), never the password itself, and URLs are recorded at the origin/path-bucket level rather than as full query strings.
Events vs. alerts
| Events | Alerts | |
|---|---|---|
| What they are | Raw observations of normal browser activity | Detections that need a decision |
| Volume | High — every navigation and login | Low — only when something is wrong |
| Severity / status | None | Severity, triage status, assignee |
| Workflow | Browse, filter, sort | Acknowledge, investigate, resolve |
| Typical use | Investigation context, baselining, discovery | Day-to-day security operations |
Many alerts are born from events: a credential attempt event with a breached password produces a Pwned Password alert; the event remains in the explorer as the underlying record.
Using the page
The page header ("Raw telemetry events collected from browser extensions") has a timeframe selector on the right: Last 24 hours, Last 7 days, Last 30 days (default), or Last 90 days. Below it, four stat cards summarize the window: Total Events, Navigation Events, Credential Attempts, and Auth Flow Events.
[SCREENSHOT PLACEHOLDER: Events page showing the timeframe selector, the four stat cards, and the Navigation tab active with event rows]
Three tabs switch between the streams, each showing its event count:
Navigation tab
| Column | Contents |
|---|---|
| Timestamp | When the navigation occurred (relative time) |
| Origin | The site that was loaded |
| Type | The navigation type (typed, link, reload, and so on) |
| Referrer | The origin the user came from, when present |
Credential Attempts tab
| Column | Contents |
|---|---|
| Timestamp | When the form was submitted |
| Origin | The site receiving the credentials |
| Fields | Chips for the detected Username and Password fields |
| Status | Blocked or Warned (policy intervened), Pwned with a breach-count bucket (breached password, no intervention), or OK |
[SCREENSHOT PLACEHOLDER: Credential Attempts tab showing rows with Username/Password field chips and a mix of OK, Warned, and Pwned status chips]
Auth Flow tab
| Column | Contents |
|---|---|
| Timestamp | When the authentication occurred |
| Origin | The authentication endpoint |
| Auth Type | The flow type (for example password login or SSO redirect) |
| IDP | The identity provider involved, when identified |
| MFA | The MFA method used, or "-" when none was observed |
All three tables support column sorting (click a header), a column visibility toggle in the toolbar, and pagination controls at the bottom for paging through large result sets. The timeframe selector applies to whichever tab is active.
The Events explorer filters by timeframe and event stream; it does not have a free-text search box. To investigate a specific domain or user, start from the related alert — its detail page links the user, device, timeline, and browsing context together — or query your SIEM if you forward events there via SIEM integration.
Worked example: verifying exposure after a phishing alert
A Phishing Suspected alert names a lookalike domain, and you want to know whether anyone actually typed credentials there.
- Open Events and set the timeframe to Last 7 days.
- On the Credential Attempts tab, sort by Timestamp and scan the Origin column around the alert time for the suspicious domain.
- A matching row with a Password field chip and status Warned confirms a user reached the login form but was warned by policy before proceeding. No OK rows for that origin means no unimpeded submission occurred.
- Cross-check the Navigation tab for the same origin to see how the user arrived — the Referrer column often reveals the delivery vector (a webmail origin, for instance).
- Record the findings in the alert's resolution notes.
Retention
Event streams are high-volume and are retained according to your deployment's data retention configuration; older events age out automatically. Retention windows and how to tune them are covered in Data Retention.
FAQ
Why is an event I expect missing? Check the timeframe selector first — the default window is 30 days. If the event is older than your retention window it has aged out. If it is recent, confirm the device was online and enrolled at the time (extensions queue events briefly while offline and send them on reconnect).
Do credential events contain passwords? No. Only metadata about the submission is recorded — field presence, breach status, and policy outcome. The password itself never leaves the endpoint.
Why is the Credential Attempts count so much lower than Navigation? Expected — navigation events fire on page loads, credential events only on login form submissions.