When people run support for production systems, the same questions about cost keep coming up. Is our cloud bill reasonable? Why did it go up? Who should worry about it? This FAQ collects the ones we hear most often and answers them in plain language, with cost per unit as the common thread. No prices appear, since every setup differs, and you should treat the answers as a way of thinking rather than a formula.
What does “unit cost” actually mean in support work?
It means taking a total, such as the monthly cost of the platform you support, and dividing it by something you can count: tickets resolved, services managed, environments kept alive, requests served. The result tells you what one of those things costs. In support, tickets and services are usually the most natural units, since your team already tracks both.
Why is the monthly total not enough?
Because it blends growth with waste. If your customer base doubled and the bill rose, that may be perfectly healthy. If the customer base stayed the same and the bill rose, something changed. The total cannot tell those stories apart, and neither can a gut feeling, however experienced the person holding it. A unit cost can, because it holds one side steady while you look at the other.
What is a sensible first unit for a managed support team?
Start with cost per service under management. Count the services you look after, take the infrastructure and tooling charges that belong to them, and divide. Add cost per ticket afterwards if you want to see the human side. Two units are plenty for the first quarter, and the habit of reviewing them matters more than the exact choice.
How can a ticket have a cloud cost at all?
Tickets themselves do not, but the problems behind them often do. A recurring alert may keep a diagnostic job running. A flaky service may be restarted repeatedly, consuming resources each time. Investigations can leave temporary copies of data behind. When you track cost per ticket, you are mostly seeing what a category of trouble costs to keep alive. That makes it a handy lens for deciding which problems are worth fixing at the root, a philosophy found in the discussion of principles for delivering software effectively.
What usually drives the number up?
In our experience, a handful of causes appear again and again.
- Capacity left on for peaks that no longer happen.
- Copies of environments nobody remembers creating.
- Logs and backups retained without a decision about how long.
- Manual work that automation would do more cheaply and more consistently.
The last item deserves a pause. Operations engineers who embrace automation often find that unit cost falls without anyone trying, a point explored in the piece on why operations engineers benefit from infrastructure as code and reliability practices.
Does a lower unit cost always mean we are doing better?
No. A falling cost per ticket might mean tickets are being closed too quickly, or that people have stopped raising them. A falling cost per service might mean monitoring was switched off. Always read the number next to a quality signal, such as customer satisfaction or the time systems stay healthy. The unit is a prompt to ask questions, not a trophy.
Who should own the number?
Nobody alone. The engineer who runs the platform understands what drives the figure, and the person who handles budgets understands what the business is willing to pay for. Shared ownership works better than either of them acting in isolation. For support teams that serve several customers, it also helps to show each customer their own unit cost, so the conversation about trade-offs involves the people who benefit from them.
Is there a formal practice for this?
Yes, it is called FinOps, and it is about letting engineers and finance colleagues look at the same cloud costs together. People who want to study it formally can look at FinOpsSchool, a FinOps training and certification provider, which offers learning online or in the classroom for roles ranging from engineers to managers.
How do I start without disrupting anything?
Run it as a side exercise. Pick one customer or one service group. Collect a month of charges and the count of services or tickets. Divide, and write down the assumptions. Share the one-page result with a colleague from outside your team. You are not changing a single system; you are changing what your team can say about the ones it already runs.
What should we avoid?
- Do not publish a unit cost without explaining how it was calculated.
- Do not use it to rank individuals or compare teams unfairly.
- Do not chase it downward at the expense of reliability.
- Do not change the method every month, or the trend will become meaningless.
How often should we look?
Monthly is enough for most support teams. Weekly looks tend to create noise, and quarterly looks arrive too late to change anything. Put the review on the calendar next to an existing meeting so it does not need its own slot. If you want to keep your hands-on skills sharp while building the habit, the walkthrough on practising DevOps at home with a hands-on tutorial is a friendly place to experiment safely with a small cost footprint of your own.
What if our customers share infrastructure?
Then you need an allocation rule, which is simply an agreed way of splitting a shared cost. Count usage if you can, such as requests or storage, and fall back on an even split only when you must. Write the rule down, tell the people it affects, and keep it stable for at least a quarter so trends mean something.
Where can I read more?
Keep reading, but also keep counting. The best teachers on this subject are your own invoices, read patiently against the things your team already measures.
