The Server Incidents Dashboard

The Incidents tab serves as your infrastructure's forensic timeline. While other resource screens focus on real-time data or continuous logging, this dashboard compiles historical anomalies, capacity breaches, and network drops into interactive visual maps. This allows engineering teams to track long-term stability patterns, spot recurring resource bottlenecks, and review historical outage durations.


1. Last 7 Days — Combined Timeline

The top panel offers a high-level operational breakdown of your system's stability over the past calendar week. Each day features a segmented horizontal bar representing a rolling timeline, concluding with your final aggregate uptime percentage on the far right.


To interpret specific timeline events, use the color-coded framework outlined in the system legend:
  • 🟢 Healthy: The server environment is fully operational, with all resources and network connections functioning within safe baselines.
  • 🪶 Resource Incident (Light Pink): The server is online, but an internal resource metric (such as CPU, RAM, or I/O Wait) has breached an active safety threshold.
  • 🟡 Some Checks Failed: An intermediate network glitch or partial packet loss occurred, where minor check variations were dropped but the host node remained reachable.
  • 🔴 All Checks Failed: A severe network connection drop or full host crash where Veyon lost complete communication with the machine.
  • ⚪ No Data (Grey): A monitoring gap—typically indicating a period when the automated check loop was manually paused, the machine was put into scheduled maintenance, or the tracking agent daemon was stopped.

2. Last 30 Days — Calendar Heatmap

The midsection expands your macro view into a trailing 30 Days Calendar grid. This view provides a bird's-eye pattern matrix showing exactly which days experienced high instability, making it easy to cross-reference crashes with manual application deployments or heavy database maintenance windows.


Incident Triggers & Severity Ratings

Days that recorded anomalies display a colored status dot alongside a counter tracking the total number of incidents that fired during that 24-hour block (e.g., a day box showing 24 with a red dot and a 5 indicates five distinct critical events occurred on the 24th of the month).

The dot colors reflect the severity assigned to the tracking rule:

  • 🔴 Critical: Severe resource exhaustion or total platform drop requiring immediate triage.
  • 🟠 High: System loads or connection delays running outside expected boundaries.
  • 🟡 Medium: Minor threshold breaches or temporary performance drops.
  • ⚫ Low: Informational metric warnings or short-lived baseline deviations.

💡 Interactive Filtering: The calendar functions as an active navigation filter. Click directly on any specific day box within the grid to instantly filter the lower triage log down to show only the incidents recorded on that calendar date.

3. Detailed Incident Triage Log

The bottom section handles root-cause forensic research, compiling every triggered alert into a structured summary row.


Triage Search & Filters

Use the inline filter bar to quickly navigate through massive event queues:

  • Search Bar: Look up incidents by keyword, service name, or specific metric comments (e.g., typing Tcp isolates connection events).
  • Severity Dropdown: Filter your view to show only high-priority issues (e.g., isolating Critical alarms).
  • Status Dropdown: Toggle your view between active unresolved alerts and historical resolved incidents.
  • Apply Button: Click to update the log grid based on your chosen filter parameters.

Anatomy of a Logged Incident Row

Every incident card presents explicit data points to help diagnose system misbehavior:

  • Alert Identification: Specifies the precise resource engine or socket that triggered the alarm (e.g., Tcp Connections Incident, Load Avg Incident, or CPU Incident), paired with the absolute peak value reached during the breach (e.g., — 278.00 or — 100.00%).
  • Breach Context: Displays the explicit operational threshold rule that was violated (e.g., critical threshold sustained).
  • Resolution Lifespan: A green badge confirms that the problem was resolved, listing the exact amount of time the server remained in a degraded state before stabilizing (e.g., resolved (6m) or resolved (38m)).
  • Execution Timestamp: The far-right column notes the exact hours and minutes the incident spanned (e.g., 19:01 – 19:07), providing the precise window you need to cross-examine application error logs or user traffic graphs.