Nobody decides to run sixty-three servers; it just turns out that you are. Here is the audit that turned each of them into one of three words, and the two columns that did more work than any metric.
Start with the decision column. Every other column exists to make one of three words defensible for one row.
Hosting bills grow the way tooling bills grow: one server at a time, each one justified on the day it was created, none of them ever revisited. Nobody decides to run sixty-three servers. It just turns out that you are.
This is the audit I ran on a hosting fleet of sixty-three virtual servers, and the method is the useful part. It works for servers, subscriptions, SaaS seats, or anything else that accumulates quietly on an invoice.
Start with the decision column, not the data
The mistake is to start by collecting metrics and hope a decision falls out. It will not. Start by writing the three possible outcomes at the top of the sheet: keep, migrate, kill. Every other column exists to justify one of those three words for one row.
Keep means the box has live traffic, is sized roughly right, and someone can name what would break if it disappeared. Migrate means the workload is real but the server is wrong: oversized, undersized, or one of four boxes doing what one could do. Kill means no sessions, no owner, and it is still on the invoice.
What to measure, and for how long
Static facts first: name, region, RAM, vCPUs, total disk, disk used. These come from the hosting console in minutes and they tell you what you are paying for. Then the facts that tell you what you are getting: average CPU and memory over fourteen days, inbound and outbound bandwidth over the same window, and monthly traffic sessions from analytics where the box serves a site.
Fourteen days is the shortest window I trust. A week catches a quiet week. A month is fine but you will not wait for it before making the first pass. Two weeks catches at least one full business cycle for most agency clients and it is short enough that people will actually let the measurement run before deciding.
Two boolean columns saved more time than any metric: does the server run the platform layer we are standardising on, and do we control its DNS. A box that runs the standard stack and whose DNS we own is cheap to migrate. A box that runs something bespoke and whose DNS the client holds is a project, and it goes in a different conversation.
Instrument what you cannot see yet
You will not have monitoring agents on every server on day one. Do not wait. Mark those cells "agent pending" and decide what you can decide from the console alone. A server with a two-gigabyte footprint, zero sessions in analytics, and no owner does not need a CPU graph to be a kill candidate. Install the agent on the ones where the decision is genuinely close.
How the sheet gets read
Sort by the decision column. Kill rows go into a ticket each with a fourteen-day notice to whoever last touched the box, then a snapshot, then deletion. Migrate rows get grouped by what they can be merged into and become a small project per group. Keep rows get an owner name written next to them, because "keep" without an owner is just "not yet".
Recheck the whole sheet quarterly. It takes an hour once the columns exist, and it is the hour that stops the fleet growing back.
What went wrong
The first pass was too clever: I tried to score each server and set a threshold. Nobody trusted a score. Three plain words that a person chose, with the metrics beside them, got agreed in one meeting. Simple and defensible beats sophisticated and opaque, every time it comes to spending someone else's money.
How to tell whether it worked
Three numbers: the count of servers, the monthly hosting line on the invoice, and how many rows have an owner. If the first two go down and the third goes up, the audit did its job. If only the sheet exists, it did not.