Match the pressure to the observed effect
| Observation | Question to investigate |
|---|---|
| CPU pressure | Which workload increased and did application response change at the same time? |
| Storage delay | Did reporting, retention, backup or other write activity overlap? |
| Memory pressure | Which processes and workload changes preceded the event? |
| Connection spike | Was the change normal growth, a reconnect event or a regional issue? |
Do not infer a platform limit from one resource metric. A component can show high utilisation while still meeting its workload; a remote dependency can slow a workflow while local utilisation remains modest.
Stabilise within the approved operating procedure
Identify the operational owner and the action permitted during an incident. A scheduled auxiliary task may be deferred if the runbook allows it; a production restart, route change or data operation needs its own authorised decision. Avoid making several unrecorded changes at once.
Record the action and watch whether the affected workflow recovers. If a restart temporarily clears the symptom, continue investigating the preceding trend rather than treating the restart as a complete capacity solution.
Choose a capacity change with a measurable purpose
Options may include separating a competing workload, changing storage, reviewing connection placement or adding appropriate resources. The right option depends on the bottleneck and the platform/provider arrangement. Re-run the representative workload after the change and compare the same signals.
Update the capacity assumptions and monitoring thresholds using the result. The hardware evaluation guide helps turn a growing workload into a testable procurement brief instead of an unsupported account-capacity claim.