Projects · Mini Hostpapa
Executive Metrics & SLOs
North-star KPIs and service objectives for HostKid: business health and platform promises at executive level.
Executive Metrics & SLOs
Alright. You have the architecture map. Boxes and arrows. Portal, ERP, engine, CloudStack, the works.
Now the question that separates a real host from a science project:
How do you know the building is safe to live in?
You cannot steer a hosting company on vibes. You cannot steer it on a Grafana wall that is green because nobody wired the alerts yet. Metrics are how leadership asks, calmly, before the customer on Twitter does: are we healthy, and are we lying to anyone?
This doc is Volume 0 for numbers: what to measure, why it matters, and what “good” looks like at launch. Not scrape configs. Not alert rule YAML. That lives in Volume 17. Not the weekly ops war room playbook. That lands in Volume 27.
Here: definitions, north stars, review habits.
Volume 11 (Corporate): ERPNext + Frappe Insights as the business cockpit.
Volume 17: Prometheus, Grafana, Loki, probes, exporters.
Volume 21 (Automation): reactive workflows when metrics cross thresholds.
Volume 27: capacity math, incident process, change failure rate in practice.
Side definitions (read once, use everywhere)
I already broke down SLI, SLO, and SLA (plus availability math and parallel vs sequence) earlier in this knowledge base. If you want the system-design lens first, read Availability patterns in Architectures → System design. The tabs below are the HostKid executive translation: same words, hosting-company context.
A number leadership actually tracks to decide something. Not every graph in Grafana is a KPI. If nobody would change behavior when it moves, it is decoration.
Rule I repeat to myself: SLO first, SLA in contracts later. Promising 99.99% without probes is marketing suicide. We document targets here so Volume 25 (Solutions Engineering) does not invent promises the platform never measured.
Where the numbers come from (executive map)
HostKid does not want “metrics” to mean “someone logged into five tools and exported CSVs.” The direction of travel is a robust observability and corporate data layer that can pull truth from the systems that already run the company, then surface straight KPI dashboards, reactive automation, and faster support without heroic manual work every Monday morning.
| Source system | Example signals | Executive consumer |
|---|---|---|
| ERPNext (Volume 11) | MRR, churn, dunning stage, invoice failures, SKU mix | Founder, finance, product |
| Frappe Insights | Margin trends, renewal recovery, cohort views, owner cockpit | Leadership |
| Portal + Platform API (Volumes 8, 10, 20) | Latency, 5xx rate, auth failures, checkout completion | Product, engineering |
| Provisioning engine (Volume 19) | Queue depth, job success, time to provision, stuck jobs | Engineering, support |
| CloudStack + hypervisors (Volume 4) | API errors, system VM health, capacity sold vs free | Infra, product |
| Monitoring stack (Volume 17) | Synthetic checks, instance reachability, DNS/mail probes later | Ops, on-call |
| Support platform (Volume 23) | MTTA, MTTR, repeat tickets, escalation rate | Support lead, everyone on incidents |
We are designing for systems that can compose queries across these sources and present executive-ready dashboards without reinventing the spreadsheet every month. Frappe Insights on ERP data is the business spine. Prometheus/Grafana/Loki is the platform spine. Automation (Volume 21) ties thresholds to reactive actions: notify, ticket, page, throttle, or pause change. Support (Volume 23) gets account + service context in one view so the first reply is informed, not archaeology.
I will go deep on wiring, query patterns, and AI-assisted anomaly surfacing in the handbook volumes. This page names what leadership expects those systems to answer.
Executive dashboard is not forty Grafana panels. It is a small set of KPIs you would interrupt dinner for: money moving wrong, provision pipeline broken, SLO burning, capacity cliff approaching, or the same incident root cause for the third week in a row.
Three metric families
| Family | Question | Who owns the story |
|---|---|---|
| Business | Is the company viable? | Founder, finance, product (pricing) |
| Product / platform | Does the machine deliver what we sold? | Product engineering, infra, ops |
| Customer | Do people stay, get helped, and recommend us? | Support, solutions, whole company on incidents |
If business metrics look fine but platform metrics are on fire, you are borrowing time. If platform metrics look fine but churn is up, you are fooling yourself about product-market fit or support quality.
Business metrics (executive)
These tie to Business model & revenue and land in ERPNext + Insights in Volume 11.
| Metric | Plain definition | Why leadership cares |
|---|---|---|
| MRR | Monthly recurring revenue from active subscriptions | Pulse of the business. One number to open the monthly review. |
| ARPA | Average revenue per account | Are we growing ticket size or stuck on the smallest SKU forever? |
| Churn rate | Customers or MRR lost in a period | Silent verdict on product, support, and billing friction. |
| Gross margin (approx) | Revenue minus direct infra cost (colo, transit, licenses you resell) | Can we scale without selling dollar bills for ninety cents? |
| Dunning recovery rate | Failed renewals that become paid again after dunning | Money stopped. This measures whether the lifecycle machine works. |
| Capacity sold vs available | CloudStack allocation vs physical headroom (rollup) | Overselling boosts revenue until it boosts outages. See below. |
| CAC payback (later) | Months to recover customer acquisition cost | When marketing spend becomes real, not lab fiction. |
Capacity discipline is not a virtuous speech. It is a number: how much CPU, RAM, storage, and IP space you have sold versus what the factory floor can deliver with margin. Business model already calls this out. Insights should show it before sales celebrates a quarter.
Lab phase honesty: revenue may be test invoices and pretend SKUs. Track the structure anyway. Empty dashboards on day one become real dashboards on day one of paying customers, instead of a panic sprint to invent KPIs under fire.
Product and platform metrics
These map to the customer lifecycle and the three operational flows on High-level architecture (Domain C).
North star (engineering)
Paid order → working service within SLO, customer notified.If you only tattoo one sentence on the provisioning wall, make it that one. Everything else is supporting cast.
Flow 1: Order-to-live (provision spine)
| Metric | Target mindset | When it screams |
|---|---|---|
| Time to provision (p50 / p95) | Minutes, not hours, for standard VPS SKUs | Queue stuck, CloudStack API errors, cloud-init failures |
| Provision success rate | High nineties for paid orders that should automate | Engine bugs, offering mismatch, entitlement desync |
| Notification sent | Customer knows service is live (email/portal) | “Payment succeeded” then silence (trust cliff) |
| Stuck job count | Near zero beyond defined retry window | Silent failures nobody pages on |
Flow 2: Payment failure and lifecycle
| Metric | Why track it |
|---|---|
| Failed renewal count | Early signal before churn shows up in MRR |
| Dunning stage conversion | Which reminder actually gets paid |
| Time to suspend | Policy automated vs manual heroics |
| Grace period outcomes | Recovered vs destroyed/archived per product rules |
Money stopped. Capacity cannot stay free forever. These metrics exist so suspend and destroy decisions stay boring, automated, and auditable, not arguments in Slack at 2 a.m.
Flow 3: Platform health (always on)
| Metric | Target mindset | Linked volume |
|---|---|---|
| Portal availability | SLO-backed, probed externally | Volume 8, 10 |
| Platform API 5xx rate | Low on checkout, provision, auth paths | Volume 20 |
| Provisioning queue depth | Bounded; alerts before hours of backlog | Volume 19 |
| CloudStack API failure rate | Rollup for create/start/stop paths | Volume 4 |
| VPS reachability (synthetic) | Data plane SLO per class | Volume 17 |
| DNS / mail health | When products live: query success, delivery signals | Volumes 12, 13 |
| Abuse / fraud incidents | Count + time to contain | Volume 22 |
Customer and support metrics
Support is where metrics meet humans. Volume 23 owns runbooks. Here we define what “good support” looks like in numbers.
| Metric | Use |
|---|---|
| MTTA (mean time to acknowledge) | Did we see the customer or the alert quickly? |
| MTTR (mean time to resolve) | Incident and ticket maturity. Not the only truth, but a honest mirror. |
| Tickets per 100 customers | Product pain proxy. Spikes after releases deserve a postmortem. |
| Repeat tickets (same root cause) | Runbook gap or platform bug pretending to be user error |
| Escalation rate | Tier 1 → engineering load. Training vs tooling signal. |
| NPS / CSAT (later) | When you have enough volume to matter statistically |
MTTA is how fast someone owns the problem. MTTR is how fast the customer is whole again. A team can have great MTTA and terrible MTTR if every ticket gets acknowledged and then sits for days.
Rapid support goal: when a ticket or page fires, the responder sees account, active services, recent provision jobs, billing state, and open incidents in one place. That is not kindness. It is metrics and integrations done right (Volumes 11, 19, 23, 17).
Starter SLOs (Maghreb launch mindset)
One zone. One rack. Honest targets. Refine with real data after the first paying customers, not before the first probe exists.
| Layer (spine) | SLI (what we measure) | Starter SLO (monthly) |
|---|---|---|
| Customer portal (public edge) | Successful HTTP availability (synthetic + real) | 99.9% |
| Platform API (private orchestration) | Success rate on auth, checkout, provision enqueue | 99.5% |
| Provisioning engine | Paid create jobs completed successfully | 99.5% |
| VPS data plane | Instance reachable (synthetic per region/class) | 99.9% |
| Authoritative DNS | Query success + latency budget | 99.99% when DNS product is live |
| Email platform | Delivery / queue health rollup | Define with Volume 13 before customer SLA |
| Internal k3s / ERP | Internal availability for staff workflows | Internal SLO, not marketed as customer SLA |
If there is no probe, no job success counter, and no ERP signal, you do not get to put a nines badge on the marketing site. SLOs here are engineering commitments. SLAs in contracts come after quarters of evidence (Volume 25).
Error budgets (executive habit)
An error budget turns SLOs into product management for reliability.
Example: portal at 99.9% monthly ≈ 43 minutes of bad minutes allowed. Deploy causes 20 minutes of partial outage? You burned half the budget. The right leadership question is not “who clicked wrong?” It is: do we freeze feature work until we understand burn rate?
| Budget state | Behavior |
|---|---|
| Green | Ship features. Keep improving observability debt on the side. |
| Yellow | Slow risky changes. Extra review on portal and engine deploys. |
| Red | Reliability work wins the sprint. Postmortem before the next big launch. |
Change management for CloudStack config already flows through Git and merge requests (High-level architecture). Error budgets are the same idea for customer-visible change: measure, then decide.
Capacity and cost signals (executive rollup)
Full math lives in Volume 27. Leadership still watches a small rollup so “we need a second rack” is a metric conversation, not a gut call.
| Signal | Question it answers |
|---|---|
| CPU / RAM / storage sold vs free in CloudStack | How close are we to oversell or hard stop? |
| Public IP utilization | Do we need another block from colo before sales promises more VPS? |
| Egress trends | Surprise bills or abuse patterns? |
| Approx cost per active VPS | Is this SKU actually profitable at current price? |
| Rack kW and physical headroom | Power and space before “just one more host” |
Second rack trigger: when sold capacity, power, and SLO burn say go, not when ego says go. Technical decisions already frame Maghreb-first expansion the same way.
Review cadence (make it a habit)
Metrics without a meeting rhythm become museum pieces.
| Cadence | Look at | Outcome |
|---|---|---|
| Weekly | Provision failures, stuck jobs, open sev-1/2, billing anomalies | Fix or assign owner before the week ends |
| Monthly | MRR, churn, dunning recovery, SLO burn, capacity headroom | Adjust pricing, catalog, or infra plan |
| Quarterly | Risk register, ISO control progress, roadmap vs catalog | Strategic bets, not only firefighting |
Weekly ops review: engineering + support + whoever owns billing integrity that week. Monthly business review: leadership + Insights dashboards. Quarterly: add governance and security leads so metrics connect to Governance, risk & compliance.
Fair people metrics (link to culture)
Core values & human engine already says evaluation should use visible department metrics, not surprise spreadsheets. That means support sees ticket quality signals, engineering sees SLO and change failure rate, product sees provision time and churn correlates. Visibility, not surveillance.
What this doc does not cover
| Not here | Where it lives |
|---|---|
| Prometheus scrape configs, alert rules, dashboard JSON | Volume 17 |
| Insights query builder, ERP report design, AI-assisted KPI workflows | Volume 11, Volume 21 |
| SLA legal language and customer credits | Volume 25 |
| Incident command, change failure rate process, capacity planning math | Volume 27 |
| Support runbooks and ticket tooling detail | Volume 23 |
Next: Governance, risk & compliance. Metrics tell you if the building is healthy. Governance tells you if you are allowed to keep operating it in regulated markets.