Server statistics paint only part of the health picture; alone they don't characterize usage. "X requests/second" means little until tied to what users are *doing* — Y simultaneous users, of whom A% upload photos, B% comment, C% browse while waiting for the pizza guy. Graphing server load against those user-action metrics reveals the **capacity cost per feature** (a comment costs more than a browse, less than an upload), which tells you where to focus planning attention. It also justifies procurement. The person approving expensive hardware is rarely the one requesting it, so framing the request in business terms — "these DB servers serve pages X% faster, so pageviews and ad revenue can rise up to Y%" — reframes technology spend as a **revenue driver, not a cost center**, and gives non-technical approvers real context. --- *Source: [[The Art of Capacity Planning]] (John Allspaw, O'Reilly 2008) — Ch 1 — Goals, Issues, and Processes in Capacity Planning*