Experience Score

The Experience Score boils a machine's day-to-day health down to one number from 0 to 10. It is built from five things a user feels: how long the last logon took, how often applications crash or hang, how responsive the machine is, how fast its slowest drive answers, and the network round trip to the Athena server. The server calculates it from each heartbeat, shows it on the machine's Resource Metrics page with a 7-day trend, and lets you filter, monitor and script against it. You decide how much each input counts and what "good" and "bad" mean for your fleet.

Where to see it#

Open a machine from the Agents list and choose Resource Metrics in the agent detail view. The Experience Score card shows:

• The score ring — the current score out of 10, with one decimal. The ring is green at 7 or more, amber from 5 to below 7, and red below 5.
• The trend line — Daily average, last 7 days. It appears once the machine has at least two days of stored daily averages.
• One chip per input — Logon, App stability, Responsiveness, Disk and Network, each with its own 0–10 sub-score and the same colours (red below 5, amber below 7). A chip that reads n/a is an input the machine did not report, or one whose weight you set to 0; it is left out of the score.

Hover the card title for a one-line summary of how the score is made. When too little is known to score the machine fairly, the card says Not enough data to score yet instead of guessing (see below).

The five inputs#

Every input is "lower is better". Each one is turned into a sub-score: 10 at its good bound or better, 0 at its bad bound or worse, and a straight line in between. With the default bounds, for example, a 52.5-second logon scores 5.0.

The fast-moving inputs — run queue, commit, hard faults and drive latency — are smoothed over roughly 10 minutes, so one busy heartbeat does not swing the score. Logon, crashes and network round trip are used as reported. A network round trip older than 5 minutes is treated as not reported.

How the score is calculated

The score is the weighted average of the inputs the machine actually reported, rounded to one decimal. Missing inputs are dropped and the remaining weights are re-balanced, so a machine is never punished for something it cannot measure. A Linux server with no logon data, for example, is scored on the other four inputs (75 of the default 100 weight).

# Default weights, every input present
score = (25 × Logon + 25 × AppStability + 25 × Responsiveness + 15 × Disk + 10 × Network) / 100

# Logon not reported (Linux / macOS): the other weights are re-balanced
score = (25 × AppStability + 25 × Responsiveness + 15 × Disk + 10 × Network) / 75

"Not enough data to score yet"

If the inputs a machine reported carry less than half of the total weight, there is no score — the card shows Not enough data to score yet, the API returns null, and filters and monitors treat the machine as having no value. With the default weights that means at least 50 of the 100 points must be present. The score is worked out from the machine's heartbeats, so a machine that has not sent one since the server started also shows this message until it does.

Tuning the score#

Go to Settings → Monitoring → Experience Score. The page has two parts:

• Weights — one number from 0 to 100 for each of Logon, App stability, Responsiveness, Disk and Network. Set an input to 0 to leave it out of the score entirely.
• Good and bad bounds — a Good and a Bad value for each measure: Last logon (seconds), App crashes and hangs in 24 h, Run queue per core, Memory commit (%), Hard faults per second, Worst drive latency (ms) and Network round trip to the server (ms). Each field shows its default underneath.

Click Save to store and apply the values. The change takes effect at once for every machine — the next time a score is shown, it uses the new weights and bounds. Reset to defaults restores Logon 25, App stability 25, Responsiveness 25, Disk 15, Network 10 and the default bounds listed above.

Validation rules

A save is refused, with the reason shown as a message, when:

Finding low scores across the fleet#

The score and its raw inputs are filter fields in the Performance category, so you can use them wherever Athena filters machines — collections, monitors, reports and tagging rules:

Built-in performance monitors

Athena ships four ready-made monitors under Settings → Monitoring → Monitors. They are disabled until you turn them on, so nothing alerts until you decide it should. Each is a Warning that checks every 15 minutes, fires after 2 consecutive failures and clears after 1 pass. You can edit or delete them like any other monitor; a deleted one is not recreated.

History#

The server stores one daily average of each machine's score (history key experience.score), next to the stored logons and daily crash and hang counts. History is kept for 7 days by default; set Performance:HistoryDays (1 to 90) in the server configuration to keep more or less. Older rows are removed automatically.

REST API#

The settings object uses these fields (defaults shown):

{
  "logonWeight": 25, "stabilityWeight": 25, "responsivenessWeight": 25,
  "diskWeight": 15, "networkWeight": 10,
  "logonGoodSeconds": 15,  "logonBadSeconds": 90,
  "crashesGood": 0,        "crashesBad": 10,
  "queuePerCoreGood": 1,   "queuePerCoreBad": 4,
  "commitPctGood": 70,     "commitPctBad": 100,
  "hardFaultsGood": 50,    "hardFaultsBad": 1000,
  "diskLatencyGoodMs": 10, "diskLatencyBadMs": 100,
  "rttGoodMs": 30,         "rttBadMs": 300
}

# Weigh the network more heavily for a branch-office fleet
$headers = @{ Authorization = "Bearer $token" }
$base    = "https://athena.example.com:8443/api/settings/experience-score"

$s = (Invoke-RestMethod -Uri $base -Headers $headers).data
$s.networkWeight = 25
Invoke-RestMethod -Method Put -Uri $base -Headers $headers `
  -ContentType "application/json" -Body ($s | ConvertTo-Json)

PowerShell#

In the Athena PowerShell module, the score is one of the samples that Get-AthenaAgentPerformance returns, under the key experience.score; the server-measured network round trip is net.rtt_ms. Both are present while the machine is online and reporting. Get-AthenaAgentPerformanceHistory returns the stored daily averages. Both cmdlets take -AgentId from the pipeline; -Key narrows the output (a wildcard for current values, one history key for history), and the history cmdlet takes -Days (1–7). For the per-input breakdown, read scoreInputs from the REST API.

# Current score and round trip for one machine
Get-AthenaAgentPerformance -AgentId "12345678-1234-1234-1234-123456789012" -Key "experience.score"
Get-AthenaAgentPerformance -AgentId "12345678-1234-1234-1234-123456789012" -Key "net.rtt_ms"

# Daily score averages for a group of machines
Get-AthenaAgent -Hostname "PC-5*" | Get-AthenaAgentPerformanceHistory -Key experience.score -Days 7

Related#

• Resource Metrics & Performance — the live values on the same page.
• Monitoring & Alerts — enabling the built-in performance monitors and working their alerts.
• Filter Fields — using the Performance fields in collections and filters.
• Agent Details View — where Resource Metrics lives per machine.
• Audit & SIEM — where score setting changes are recorded.