Events

Purpose

Events provides the operational timeline for actions across virtual machines, storage, network, and platform services.

When to Use

Use this page when you need to confirm what happened, who triggered it, and when it occurred.

Step: Start Events Workflow

When to Use:

Use this at the start of event-based incident triage.

Purpose:

Capture the minimum evidence needed for accurate escalation.

Steps:

1. Open Control Center -> Observability -> Events.

2. Apply filters (level/resource/search) to isolate incident-window rows.

3. Open one event row and capture Type, State, Level, Created At, and Resource ID.

4. Use captured values to build triage or escalation notes.

Expected Outcome:

• You can produce an accurate action timeline with enough context for follow-up.

If this fails:

1. Refresh the page and re-apply filters.

2. Continue with detailed steps in the included guide.

When to Use Events

Use Events when you need a comprehensive audit log of platform actions, user activity, and operation outcomes.

Step: Review Events

When to Use:

Use this first when starting incident triage from the Events timeline.

Purpose:

Identify high-risk operation failures quickly and establish timeline context.

Steps:

1. Open Control Center -> Observability -> Events.

2. Confirm the events table is loaded with the latest rows.

3. Start triage with Level=ERROR and State=Failed to isolate high-risk operations first.

4. Expand to additional filters after initial triage.

Events dashboard.

Tip

Start with Level=ERROR + State=Failed first, then widen scope to include related WARNING and INFO rows.

Warning

Event history is policy-based and often time-limited. Capture required incident evidence in the same session.

Expected Outcome:

• You can identify high-risk rows quickly from state and level.

• You can explain what happened, who triggered it, and when.

If this fails:

1. Refresh the page.

2. Re-apply Level=ERROR and State=Failed filters.

Step: Open Events Help

When to Use:

Use this when column, state, or level meanings are unclear during triage.

Purpose:

Confirm page-specific field definitions before acting on results.

Steps:

1. On the Events page, click the help icon.

2. Review definitions for columns, state, and level meanings.

3. Return to the table and continue triage with the same filters.

Events help panel.

Expected Outcome:

• You can interpret Events fields consistently before filtering or escalation.

If this fails:

1. Refresh the page and reopen help.

2. Continue with field definitions from this guide if panel access is unavailable.

What the Events Table Shows

Column	Description
Type	Event/operation type (for example VM.CREATE, VM.DESTROY, FIREWALL.CLOSE, ISO.CREATE, VOLUME.CREATE). Click to filter by type.
State	Current operation status (Completed, Started, Scheduled, Created, Failed).
Level	Severity level (INFO, WARNING, ERROR).
Resource Type	Resource impacted by the event (for example VirtualMachine, Volume, Boot Image, Network).
Username	User who initiated the operation.
Account	Account associated with the event.
Domain	Domain/organizational scope for the event.
Created At	Event timestamp in DD/MM/YYYY HH:MM:SS format.

Event Type Reference

Category	Common types	What it tracks
VM operations	VM.CREATE, VM.START, VM.STOP, VM.DESTROY, VM.REBOOT, VM.MIGRATE, VM.SNAPSHOT	VM lifecycle and mobility operations.
Volume operations	VOLUME.CREATE, VOLUME.DELETE, VOLUME.ATTACH, VOLUME.DETACH, VOLUME.RESIZE	Volume provisioning and attachment lifecycle.
Network operations	FIREWALL.CREATE, FIREWALL.DELETE, FIREWALL.CLOSE, NETWORK.CREATE, NETWORK.DELETE	Network and firewall changes.
Storage operations	ISO.CREATE, ISO.DELETE, SNAPSHOT.CREATE, SNAPSHOT.DELETE (ISO.* events correspond to Boot Images actions in the UI)	Boot image and snapshot actions.
User/security operations	USER.CREATE, USER.DELETE, USER.UPDATE, LOGIN, LOGOUT	Identity and access-related events.
Infrastructure operations	CLUSTER.CREATE, CLUSTER.DELETE, HOST.ADD, HOST.REMOVE	Cluster/host lifecycle changes.
System operations	BACKUP, CONFIG.UPDATE, ALERT, ERROR	Platform-level maintenance and failure signals.

State and Level Reference

State badges:

State	Meaning	Operator guidance
Completed (green)	Operation finished successfully.	No immediate action unless additional validation is required.
Started (green)	Operation in progress.	Monitor to completion for long-running tasks.
Scheduled (yellow)	Operation queued; not started yet.	Verify prerequisites and resource availability if it remains queued.
Created (yellow)	Operation/resource created but not fully processed.	Check for required follow-up steps if it does not advance.
Failed (red)	Operation did not complete.	Investigate and remediate before rerun.

Level badges:

Level	Meaning	Operator guidance
INFO (green)	Normal informational signal.	Use for timeline/audit context.
WARNING (yellow)	Potential issue; recoverable condition.	Monitor and investigate if repeated.
ERROR (red)	Failed operation or critical issue.	Prioritize investigation and escalate when required.

Tooltip and UI Cues

Use these in-screen cues during triage:

• Type values are clickable for quick type filtering.

• State and Level badge colors provide immediate status/severity context.

• Created At gives precise sequencing for correlation with alerts and diagnostics.

• Pagination controls (page size, page navigation, result count) help navigate larger result sets.

Step: Filter and Search Events

When to Use:

Use this when raw event volume is too large for direct triage.

Purpose:

Narrow results to one action path or one incident window.

Steps:

1. Filter by Type to isolate one operation path (for example VM.CREATE).

2. Filter by Level to prioritize ERROR and WARNING rows.

3. Filter by State to focus on Failed or long-running states.

4. Filter by Resource Type to isolate VM, volume, network, or image operations.

5. Filter/search by Username for user-level activity tracking.

6. Apply date/time window filters for incident-window analysis.

7. Use keyword search for resource names, IDs, or specific strings.

8. Use pagination controls (page size + navigation) for larger datasets.

Expected Outcome:

• Results are narrowed to actionable rows without losing incident context.

If this fails:

1. Re-apply Level=ERROR and State=Failed.

2. Narrow the incident time window.

3. Filter by Resource Type or Username to isolate one action path.

4. Re-check with one additional correlated filter only (avoid over-filtering).

Step: Open Single Event Details

When to Use:

Use this after identifying a high-risk row that needs escalation context.

Purpose:

Capture event and resource metadata in one place for accurate handoff.

Steps:

1. From Events, open a target row (by clicking the event entry).

2. In Event Information, confirm:

• Type

• State

• Level

• Description

• Created At

3. In Resource Information, capture:

• Resource Type and Resource Name

• Resource ID

• Account / Username / Domain

4. Use these fields in incident tickets or escalation notes.

Warning

Failed operations can leave resources in partial state. Verify current resource state before retrying any operation.

Single event details view.

Expected Outcome:

• Type, State, Level, and Created At are captured.

• Resource ID and ownership context (account/user/domain) are captured.

• One escalation note can be written without returning to the table.

If this fails:

1. Reopen the event row from the filtered table.

2. Capture available metadata and continue with correlated alerts if detail data is partial.

Expected Outcome

• You can quickly isolate failed operations.

• You can produce an auditable timeline of who changed what and when.

• You can escalate with complete evidence (event + resource + ownership context).