Storage Health Checks: Metrics and Recommended Practices

Most storage incidents are not surprises. By the time an aggregate fills up or a SnapMirror relationship breaks, the warning signs were sitting in system health alert show or a disk error log for days. A storage health check is just the discipline of reading those signs on a schedule instead of after a ticket comes in. This post walks through a practical routine built entirely on real ONTAP CLI commands, organized by what actually causes outages: cluster and node health, capacity, disks, snapshots and replication, networking, performance, and the housekeeping items (AutoSupport, licenses, time sync) that affect supportability and recovery when left unresolved.

Cluster and Node Health

Start at the top. If a node is down or out of quorum, address cluster membership and node health first.

cluster show
cluster ha show
system node show -fields health,uptime,model
system health status show
system health alert show

cluster show confirms every node is healthy and eligible for cluster membership. cluster ha show tells you whether HA is actually enabled and configured on each pair — a surprising number of environments run for months with HA silently disabled after a node was serviced. system health status show gives a single ok/degraded verdict, and system health alert show lists the specific subsystem alerts behind a "degraded" status. Treat any active alert as something to triage the same day, not the same quarter.

Capacity: Aggregates and Volumes

Capacity exhaustion is often preventable because utilization trends can be detected in advance.

storage aggregate show -fields size,usedsize,availsize,percent-used-capacity
storage aggregate show -state !online
volume show -fields size,used,percent-used,state,space-guarantee

The following are practical starting thresholds, not universal vendor limits. Adjust them for the platform, workload, snapshot growth, storage-efficiency behavior, support guidance, and the time required to add or move capacity:

• 70-80% aggregate utilization — plan capacity work now, not urgently.
• 85-90% — treat as a real problem: free space, add disks, or migrate volumes.
• 95%+ — active incident. Aggregate-full conditions can block Snapshot creation and even writes.

The storage aggregate show -state !online filter is worth running on its own — an aggregate stuck in a non-online state (restricted, creating, failed) is far more urgent than one that's simply full, and it's easy to miss in a wall of green output.

Disk and RAID Health

storage disk show -broken
storage disk error show
storage aggregate show -fields raidstatus
storage shelf show

storage disk show -broken should return nothing on a healthy system — if it doesn't, check whether a spare is already rebuilding before you do anything else. storage aggregate show -fields raidstatus catches a RAID group stuck in a degraded or reconstructing state even when every individual disk looks fine on its own. storage shelf show adds shelf-level health information; a shelf with a failed power supply or a marginal ACP connection won't show up in disk-level commands at all until a second failure turns a routine event into data loss.

Snapshots and Space Reclamation

volume snapshot show -fields size
volume snapshot policy show
volume show -fields size,percent-used,percent-snapshot-space

Snapshot reserve creeping past its configured percentage is usually the real cause behind a volume that "suddenly" reports high utilization. Check percent-snapshot-space alongside overall percent-used — if the gap between the two is large and growing, either the snapshot schedule is too aggressive for the change rate on that volume, or something (a botched restore, a runaway application) is generating snapshots faster than they're aging out.

Data Protection: SnapMirror Health

snapmirror show -fields state,lag-time,healthy
snapmirror show -instance -destination-path svm:volume
snapmirror policy show

The healthy field is the fast triage check — snapmirror show -fields state,lag-time,healthy across every relationship takes seconds and tells you exactly which ones need attention. Lag time matters more than most teams treat it: a relationship that's "healthy" but running three hours behind schedule is still eating into your actual recovery point objective, and that gap tends to widen quietly until a transfer window gets missed entirely.

Network Ports and LIFs

network port show -fields link,health-status
network interface show -failover
network interface show -is-home false

network interface show -is-home false is one of the most useful one-liners in this whole routine — it lists every LIF that has failed over off its home port and never failed back. That's often the first evidence of a network event nobody reported, and it directly affects your failover headroom the next time something actually breaks.

Performance and Latency

qos statistics workload latency show
statistics show-periodic -object volume -counter total_ops,avg_latency
system node run -node <node> -command "sysstat -c 10 1"

You don't need a full performance deep-dive as part of a routine health check — just a baseline. Latency numbers only mean something in the context of what's normal for that workload; a volume that runs at 2ms and jumps to 8ms is a real signal even though 8ms would be unremarkable for a different workload entirely. Note the baseline once, then watch for deviation from it rather than judging any single number in isolation.

AutoSupport, Licenses, and Time Sync

system node autosupport show -node *
system license show
cluster time-service ntp server show
security certificate show -fields expiration

These four checks may not indicate an immediate outage, but they affect supportability, authentication, and maintenance. A silently disabled AutoSupport means NetApp support has no telemetry when you actually need a case escalated quickly. Expired feature licenses can quietly disable functionality your DR runbook assumes is available. Clock drift breaks Kerberos authentication and makes correlating logs across nodes unreliable. And an expired certificate has a way of failing exactly during a maintenance window, not before it.

Putting It Into a Routine

None of this needs to be a daily ritual across every command above. A workable cadence:

Daily commands

system health alert show
storage disk show -broken
snapmirror show -fields state,lag-time,healthy

Review active health alerts, broken disks, and replication state and lag. Investigate new exceptions the same day.

Weekly commands

storage aggregate show -fields size,usedsize,availsize,percent-used-capacity
volume show -fields size,used,percent-used,state,space-guarantee
network interface show -is-home false
system node autosupport show -node *

Compare aggregate and volume capacity with the previous week. Review non-home LIFs and confirm AutoSupport remains enabled and operational.

Monthly commands

system node show -fields health,uptime,model
system license show
cluster time-service ntp server show
security certificate show -fields expiration
qos statistics workload latency show

Review node maintenance status, licenses, NTP configuration, certificate expiration, and workload latency against the established baseline. Capture the output so month-to-month changes remain visible.

Script the daily and weekly checks if you can — the value of a health check isn't the command, it's noticing the trend before it becomes an incident. The commands above are the same ones you'd reach for during an outage; running them on a schedule just means you're reading them before the outage instead of during it.

Version and source note

CLI fields and operational thresholds can differ by ONTAP release and platform. Confirm every command against the current ONTAP command reference and tune alert thresholds from measured growth and workload baselines.