Get-StorageReliabilityCounter: Temperature, Wear, and Errors

Get-StorageReliabilityCounter reads reliability information exposed for a Windows disk or physical-disk object. Depending on the device and storage provider, it can return temperature, wear, power-on time, and error counters.

Some fields may be blank, and some queries may be unsupported. Blank is not zero, and a successful query is not a complete health test.

Start by selecting the correct device, then interpret the fields that are actually available.

Identify one physical-disk object

Open Windows PowerShell as administrator. The examples use the Windows Storage module and only query information; they do not repair, reset, or format a drive.

First retain the objects and display their identity:

$physicalDisks = @(Get-PhysicalDisk -ErrorAction Stop)
$physicalDisks |
    Select-Object DeviceId, FriendlyName, SerialNumber,
        UniqueId, BusType, Size |
    Format-List

Match the model, serial number where available, capacity, and connection to the intended device. Keep identifiers private when sharing output.

The DeviceId shown here belongs to the physical-disk provider view. Do not assume it is the same number as a Windows disk shown by Get-Disk.

For these storage views, see Get-Disk vs Get-PhysicalDisk: Why the Lists Differ.

If an enclosure or RAID controller exposes an unexpected object, resolve that identification question first. The command cannot reveal every underlying component merely because its name contains “PhysicalDisk.”

Run Get-StorageReliabilityCounter

In the same session, replace the placeholder with the exact UniqueId from the confirmed object:

$targetId = 'PASTE-EXACT-PHYSICAL-DISK-UNIQUEID-HERE'
if ([string]::IsNullOrWhiteSpace($targetId)) {
    throw 'A confirmed nonempty UniqueId is required.'
}
$selected = @($physicalDisks | Where-Object {
    $_.UniqueId -eq $targetId
})
if ($selected.Count -ne 1) {
    throw 'Expected one physical disk. Review the inventory.'
}
$counter = @(Get-StorageReliabilityCounter -PhysicalDisk $selected[0] -ErrorAction Stop)
if ($counter.Count -ne 1) {
    throw 'Expected one counter object. Review the provider result.'
}
$counter |
    Select-Object DeviceId, Temperature, TemperatureMax, Wear,
        PowerOnHours, ReadErrorsTotal, ReadErrorsCorrected,
        ReadErrorsUncorrected, WriteErrorsTotal,
        WriteErrorsCorrected, WriteErrorsUncorrected |
    Format-List

The selection guards prevent an ambiguous match from being treated as one device. If the identifier is missing or not unique, stop and establish another reliable association instead of deleting the guard.

The command also accepts a Disk object through its -Disk parameter. That is a different input view; it is not an automatic way to reach a hidden RAID member.

Keep the input identity alongside the counter result. The counter’s DeviceId is defined in relation to the associated object, so identical digits from different query paths are not enough to establish equivalence.

Read the fields according to their definitions

TemperatureMax is not defined as the highest temperature ever observed. Do not use it as a historical temperature record merely because the name ends in Max.

Wear is not a remaining-life percentage. If a provider supplies Wear = 20 according to this definition, it describes estimated wear consumption. It does not mean the drive has only 20% remaining.

A simple 100-minus-Wear calculation is not a universal replacement for a manufacturer’s health percentage. Different tools can expose different estimates, and neither figure can be converted into a guaranteed number of remaining days.

For the separate CrystalDiskInfo display, see CrystalDiskInfo Says Good 80%: What Does It Mean?.

Keep missing values separate from reported zero

Consider this illustrative result:

The blank Wear field is not evidence of a brand-new or unworn SSD. The zero error count is also only the reported value for that field; it does not prove that every file or storage path is healthy.

If you export or transform results, preserve null values. Casting a missing field to an integer can turn it into zero and erase the distinction.

A returned value that is implausible for the device deserves investigation too. Compare it with the manufacturer’s supported utility and the documented field mapping before assigning it a meaning.

What to do when the query is empty or unsupported

Keep the exact error text and the selected device’s identity. Distinguish four outcomes: a missing command, an access failure, an unsupported provider operation, and a returned object with missing properties.

Do not assume an error means that the drive itself has failed. Equally, do not label it healthy because the command supplied no warning.

Check whether the manufacturer supports a diagnostic tool for that model and connection. USB enclosures and RAID controllers can restrict health reporting, so another utility may have the same limitation.

For the USB enclosure case, see Why CrystalDiskInfo Cannot See an External SSD.

Avoid opening sealed products or changing a storage mode simply to obtain a counter. Resolve the supported query path with the vendor when necessary.

Use changes and symptoms together

Save readings with a timestamp and the same device identity. Compare a specific counter over a documented period, using the same provider and connection where practical.

Do not add corrected and uncorrected counts from different devices or tools, and do not equate these Windows fields automatically with similarly named raw NVMe fields.

For the NVMe definitions, see NVMe Unsafe Shutdowns vs Media Errors.

If uncorrected errors appear or increase, protect data and investigate. If the drive disconnects or files fail to read, investigate those symptoms even when available counters remain zero.

The useful output is a set of named, scoped measurements with unknowns preserved. That makes the result suitable for a support request or a later comparison without giving a limited query more authority than it has.