Define the symptom

Record when the problem occurs, which applications are affected and whether the issue is CPU, memory, disk or network related. Capture the VM size and operating system before making changes.

Use Azure Monitor signals

Review CPU, disk and network metrics over the incident window. Look for sustained saturation versus short spikes. A single high metric does not establish the root cause.

Run performance diagnostics

Azure performance diagnostics can collect data and provide insights for high CPU, memory and disk usage. Use the resulting report to guide the next test rather than treating it as an automatic fix.

Correlate with Windows counters

For Windows workloads, correlate Azure metrics with Performance Monitor counters and application logs. This can reveal whether high disk latency is caused by a storage workload or an application queue.

Check recent changes

Review VM resize operations, application deployments, Windows updates, scheduled tasks, backup jobs and security scans. A performance incident often starts with a change that happened shortly before the symptom.

Validate the remediation

After a change, monitor the same metrics for a representative period and compare them with the baseline. Document the evidence used to close the incident.

Useful commands

Get-Counter '\Processor(_Total)\% Processor Time'
Get-Counter '\Memory\Available MBytes'
Get-Counter '\LogicalDisk(*)\Avg. Disk sec/Read'
Production checklist: capture the original state, test one dependency at a time, make the smallest controlled change and validate the original symptom before closing the incident.

What good troubleshooting looks like

Use evidence before configuration changes. Record the symptom, test result, change made and validation result so another engineer can repeat the procedure.

Workflow
Symptom → hypothesis → direct test → controlled change → validation → documentation

Frequently asked questions

What should I check first?

Start with the exact failed path or dependency and test it directly before changing configuration.

Should I change production configuration immediately?

No. Capture the current state first and make one controlled change at a time.

How should I document the fix?

Record the symptom, commands, result, configuration change and validation result.

Related TechRunbook guides

Primary reference

This guide was independently written for TechRunbook. Technical details were checked against current Microsoft documentation. Microsoft Learn reference →

Need more infrastructure runbooks?

Explore the TechRunbook article library for Windows Server, VMware, Hyper-V, Azure, PowerShell and MABS troubleshooting.

Browse all articles →