Services Inventory
For every managed machine, Athena inventories the services installed on it — the background programs that start with the operating system and keep running in the background. On Windows these are Windows services; on Linux they are systemd units. For each service Athena records its name, display name, status, and startup type, so you can answer questions like “is the print spooler running on every workstation?” or “which servers still have a legacy service set to start automatically?” from one console instead of logging on to each box.
Inventory vs. live control. This page is about the inventory — the collected, searchable, and reportable list of services on each machine. To actually start, stop, or restart a service on a connected Windows machine, or to view its full properties, see Remote Windows Services Control.
What's collected#
For each service on a machine, Athena records:
| Field | Meaning |
|---|---|
| Service Name | The short, internal name of the service — for example wuauserv, Spooler, or W32Time on Windows, or a systemd unit name such as sshd on Linux. |
| Display Name | The friendly, human-readable name — for example “Windows Update” or “Print Spooler”. On Linux this is the unit's description. |
| Status | The service's current run state — Running, Stopped, Paused, and (on Windows) transitional states such as start/stop pending. See Platform coverage. |
| Startup Type | How the service is configured to start — for example Auto, Manual, or Disabled. |
Platform coverage#
Services are inventoried on both Windows and Linux endpoints, using each operating system's native facilities. The four fields above are the same on both platforms, but the values differ in the ways you would expect:
| Windows | Linux | |
|---|---|---|
| Source | The Windows Service Control Manager. | The systemd service manager (systemctl), including inactive units. |
| Service Name | The service's registered short name. | The unit name (without the .service suffix). |
| Display Name | The friendly display name. | The unit's description text. |
| Status | Running, Stopped, Paused, or a transitional state. | Running when the unit is active, otherwise Stopped. |
| Startup Type | Auto, Manual, Disabled, and related modes. | Auto when the unit is loaded, otherwise Manual. |
Naming note. The category is labelled Services throughout the
console and covers both Windows services and Linux systemd units. In the API and
report/filter field names you may see the underlying key spelled with a Windows prefix
(for example windowsServices); it carries the services collected from Linux machines as
well.
Where to see it#
Open a machine from the Agents list, then in the agent detail view's left-hand navigation choose Services. The section lists services in a table with columns for Service Name, Display Name, Status, and Startup Type, ordered by display name. A colour-coded status badge marks running, stopped, and paused services at a glance.
A search box above the table filters as you type and matches on both the service name
and the display name, so you can type sql to find every SQL-related service or
spool to jump straight to the print spooler.
Live vs. cached. When the machine is connected, the Services section shows a Live badge and reads the current service list directly from the machine, and (on Windows) offers inline Start / Stop / Restart actions and a properties view — see Remote Windows Services Control. When the machine is offline, a Cached badge is shown and the section falls back to the last inventory snapshot the machine reported. The inventory snapshot — the cached list — is what the fleet-wide filters, collections, and reports below are built on.
Targeting and reporting across the fleet#
Unlike some inventory categories, services are a filterable field, so you can build fleet-wide rules and reports on them without writing a custom scan. Four service fields are available to dynamic collections, automatic tagging rules, and the report builder:
| Field | Type | Example values |
|---|---|---|
Services.ServiceName | String | wuauserv, W32Time, Spooler, MSSQLSERVER |
Services.DisplayName | String | Windows Update, Print Spooler, SQL Server |
Services.Status | String | Running, Stopped, Paused |
Services.StartupType | String | Auto, Manual, Disabled, Automatic (Delayed) |
Because a machine has many services, these fields match with “any service”
semantics: a machine matches a service condition when at least one of its services satisfies
it. For example, a dynamic collection with Services.DisplayName contains
SQL Server gathers every machine that has a matching service, and
Services.ServiceName equals Spooler gathers every machine that has
the print spooler installed. As String fields they support the usual text operators —
equals, not equals, contains, not contains,
starts with, and ends with. See the
Filter Field Reference for the full operator table.
For a tabular export, the report builder includes a dedicated Services data source that produces one row per service, per machine. Its columns are Machine Name, Operating System, Agent Status, Service Name, Display Name, Status, and Startup Type — ideal for a “which machines are running (or not running) service X” report across the fleet. See Reports to build, save, and export it.
What it's good for#
- Compliance checks — confirm a required security or management service is
Runningeverywhere it should be, or find machines where it isStoppedorDisabled. - Attack-surface review — locate machines still running a legacy or unwanted service, or one set to start automatically that should not be.
- Grouping by role — build a collection of every
database server (has an
MSSQLSERVERservice) or every web server, then deploy and report against that group. - Troubleshooting — check a service's status and startup configuration on a single machine before deciding whether to remediate it.
Reading it over the API#
Services are part of an agent's inventory. You can fetch just the services list for one machine, or read them from the full inventory document. Reading inventory requires the Helpdesk role or higher.
| Endpoint | Returns | Role |
|---|---|---|
GET api/agents/{agentId}/inventory/services | The services list for one machine (name, display name, status, startup type). | Helpdesk or higher |
GET api/agents/{agentId}/inventory | The full inventory document; read the windowsServices array. | Helpdesk or higher |
# Fetch just the services list for one agent
$headers = @{ Authorization = "Bearer $token" }
$services = Invoke-RestMethod `
-Uri "https://athena.example.com:8443/api/agents/$agentId/inventory/services" `
-Headers $headers `
-SkipCertificateCheck
# Services that are set to start automatically but are not running
$services.data |
Where-Object { $_.startupType -eq 'Auto' -and $_.status -ne 'Running' } |
Select-Object serviceName, displayName, status, startupType
The Athena PowerShell module wraps the same endpoint with a dedicated cmdlet, which also accepts a
-Search substring and can be piped an agent:
# All services on a machine
Get-AthenaAgentServices -AgentId $agentId
# Filter to matching services by name/display name
Get-AthenaAgentServices -AgentId $agentId -Search "sql"
# Find automatic services that should be running but are not
Get-AthenaAgentServices -AgentId $agentId |
Where-Object { $_.StartupType -eq 'Automatic' -and $_.Status -ne 'Running' }
Each service carries serviceName, displayName, status, and
startupType. The list is empty or absent when a machine has not yet reported this data.
For the wider inventory surface and the PowerShell module used to script against the server, see
Inventory and the
PowerShell Module reference.