Capacity reporting and stakeholder communication

Engineering teams measure success in uptime, latency, and error rates. Stakeholders measure success in revenue, productivity, and risk. This lesson bridges the two: how to communicate cluster performance in terms stakeholders understand.

The translation problem

Engineering says: “P99 latency was 12ms last month.”

Stakeholders think: “Is the application slow?”

Engineering says: “We have 35% capacity remaining on the storage pool.”

Stakeholders think: “Will we run out of disk and have an outage?”

The bridge is business metrics expressed in technical terms and vice versa:

“12ms p99 latency” → “Customers experience no delay on the website”
“35% capacity” → “We can support the planned business growth for 6 more months without buying more hardware”

Stakeholder-facing dashboard

A dashboard for stakeholders looks different from an engineering dashboard. Engineering wants granular metrics; stakeholders want answers.

Top row — business impact:

Application availability (target: 99.9%)
Performance against SLO
Number of incidents this month
Mean time to recovery (MTTR)

Second row — capacity forecast:

Storage used / forecast (next quarter)
Memory used / forecast
CPU used / forecast
Network used / forecast

Third row — risk indicators:

Backup success rate
Failed verify jobs
Unpatched security advisories
HA configuration health

Bottom row — cost:

Infrastructure cost per VM
Cost per TB of storage
ROI vs cloud

Build this in Grafana with a separate dashboard from the engineering dashboards. Different audience, different metrics.

Quarterly business review

Once per quarter, present to stakeholders:

Q1 2024 Cluster Review

Reliability:
- Uptime: 99.97% (target: 99.9%)
- Incidents: 2 (1 minor, 1 major)
- MTTR: 18 minutes (target: 30 minutes)

Performance:
- VM density: 18 VMs per host (industry average: 12)
- Storage IOPS: 95k sustained, 250k peak

Capacity:
- Storage: 65% used, 6 months runway at current growth
- Memory: 72% used, 4 months runway
- CPU: 55% used, 8 months runway

Risk:
- 0 unpatched security advisories
- 0 failed backups
- 3 minor performance degradations
- 1 HA failover (planned, validated)

Investment needed:
- Storage: +20 TB in Q3 ($Xk)
- Memory: +256 GB in Q2 ($Yk)
- Replacement node in Q4 ($Zk)

The numbers should answer stakeholder questions:

“Are we reliable?” (uptime vs target)
“Are we efficient?” (density, cost)
“What’s our risk?” (unpatched CVEs, failed backups)
“What’s the cost trajectory?” (forecast vs actual)

Translating technical incidents to business impact

When a major incident happens, the post-incident report needs both technical and business sections:

Incident: VM-200 (payment processing) slow 2024-01-15

Technical:
- Root cause: storage backend saturation during backup window
- Duration: 47 minutes
- Resolution: spread backup jobs across night, added SSD tier

Business impact:
- Customers affected: ~2,300 checkout attempts delayed
- Estimated revenue impact: $4k-$8k (based on conversion rates)
- Reputation impact: 47 customer complaints, 2 social media posts
- SLA: 99.9% target was met for the month (this incident was 0.06%
  of the month's allowed downtime)

The business impact numbers are hard to calculate exactly but the attempt is what stakeholders value.

Justifying infrastructure investment

The CFO asks: “Why do we need to buy more servers?”

Engineering answers with data:

Storage capacity forecast:
- Current: 65 TB used of 80 TB (81% utilisation)
- Growth rate: 4 TB/month
- Runway: 4 months
- Date we hit 95% (cluster stops accepting writes): August 2024

Cost of action:
- Buy 20 TB SSD ($Xk)
- Time to install: 1 hour during maintenance window
- Capacity extends to: December 2024

Cost of inaction:
- August 2024: cluster stops accepting new VMs and backups
- Business impact: lost development capacity, lost customer data
  (no backups for new state)
- Estimated cost: $Yk in lost productivity + customer churn
- Recovery time: emergency hardware procurement + restore, ~1 week

When stakeholders see the cost of inaction exceeds the cost of action by 10x, the budget conversation gets easier.

Production considerations

Dashboards are not reports. A dashboard shows current state; a report tells a story. Quarterly reviews tell stories.
Frequency matches the audience. Daily for engineering, weekly for managers, quarterly for executives.
Honesty wins. Inflating metrics to look better backfires when the next incident reveals the truth. Stakeholders trust honest data.
Connect to business outcomes. “CPU at 80%” doesn’t matter to a CFO. “Application latency is degrading, which is reducing conversion rate” matters.

Common mistakes

All engineering, no business. A dashboard full of CPU graphs doesn’t tell the CFO anything useful.
Cherry-picking metrics. Reporting only the good numbers makes the dashboard meaningless.
No actionable items. A dashboard without “what should we do” is just data, not information.

Key takeaways

Translate technical metrics into business outcomes.
Build a stakeholder dashboard separate from engineering dashboards.
Run quarterly business reviews with capacity forecasts and risk assessments.
Use data to justify investment; show the cost of inaction.