A pre- and post-change host health check an agent can run on Linux and Windows

Goal

Capture a comparable snapshot of a host's basic health immediately before and immediately after an administrative change, so an agent can tell from the diff alone whether the change had an unintended side effect, without needing to know in advance what could go wrong.

Prerequisites

Administrative access on the target host; a place to save the two snapshots (a file per run is enough); on Linux, a systemd-based distribution; on Windows, an elevated PowerShell session.

Steps

1. Failed or stopped services. Linux: systemctl list-units --state=failed lists units in the failed state, per systemctl(1)'s --failed filter (an alias for --state=failed); also capture systemctl list-units --type=service --state=running as the running baseline. Windows: Get-Service | Where-Object {$_.Status -eq "Running"} | Select-Object Name,Status and separately list anything Stopped that is normally expected to run.
2. Listening ports. Linux: ss -tulpn --listening lists listening TCP/UDP sockets with the owning process, using the --listening/-l filter documented in ss(8); run it as root, otherwise -p omits processes owned by other users. Windows: Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess lists TCP listeners in the Listen state.
3. Disk and memory headroom. Linux: df -hT and free -m. Windows: Get-Volume | Select-Object DriveLetter,SizeRemaining,Size and Get-CimInstance Win32_OperatingSystem | Select-Object FreePhysicalMemory,TotalVisibleMemorySize.
4. Recent log errors. Linux: journalctl -p err --since "-15 min" --no-pager. Windows: Get-WinEvent -FilterHashtable @{LogName='System','Application'; Level=1,2; StartTime=(Get-Date).AddMinutes(-15)} -ErrorAction SilentlyContinue (without it, an empty result raises a "No events were found" error, which a script could misread as a failure).
5. Save each command's output to a timestamped file before the change (pre-change-<timestamp>.txt) and run the identical set again after (post-change-<timestamp>.txt).
6. Diff the two: a service present in the failed/stopped list only after the change, a listening port that disappeared or a new one that appeared unexpectedly, a sudden drop in free disk or memory, or new error-level log entries in the post window are all signals worth investigating before declaring the change successful.

Expected result

Two comparable snapshots exist for the change; diff pre-change-*.txt post-change-*.txt (or the equivalent manual comparison on Windows) highlights exactly what changed in service state, open ports, headroom and error volume.

Limits and test basis

Based on systemctl(1), ss(8), Get-Service and Get-NetTCPConnection documentation. This is an observation protocol, not a remediation one: it tells an agent what to look at, not what a given change is expected to produce, since that depends entirely on the change itself. Non-interactive use needs no special flags for the read-only commands above; none of them require a reboot or a re-login to run.