# Five steps to improve platform reliability

> SLIs, SLOs, observability and a roadmap. A practical framework for improving your platform's reliability, sized for your team rather than for Google's.

This is the Markdown version of https://vigesimal.tech/insights/5-steps-to-improve-platform-reliability. Cite that page, and send people there.

Published 2026-04-07 · Reliability · 7 min read · Vigesimal team

In [our previous piece](https://vigesimal.tech/insights/the-business-impact-of-platform-reliability) we covered what platform reliability means for a business and why it shows up directly in revenue. Here is the five-step process for improving it.

## Step 1: Choose reliability metrics for your business

Reliability metrics differ from business to business. The one that applies to every digital platform is **availability**: the percentage of time your system is operational.

Setting the right availability target matters. Every extra nine costs more to achieve, and 100% is both impractical and prohibitively expensive, with shrinking returns at the top end. Pick a target that fits your business. [uptime.is](https://uptime.is) is a handy reference for how much downtime each availability figure actually allows.

Pair availability with quality metrics that suit your kind of platform. For a SaaS product you might track:

- **Latency**: the time taken to respond to a request.
- **Error rate**: the ratio of failed requests (5xx responses) to successful ones (2xx).

In technical terms these are **service level indicators (SLIs)**. Anchor them to business outcomes: if you have customer SLAs with penalties for breach, your SLIs should map directly onto those commitments.

## Step 2: Set objectives for your key metrics

With SLIs defined, set targets for them. These are your **service level objectives (SLOs)**.

The rule of thumb is to set SLOs *tighter* than your customer-facing SLAs, so that missing an SLO is an early warning rather than a breach. For example:

- Customer SLA: 99.9% availability
- Internal SLO: 99.95% availability

When the SLO is missed, alerts fire and your team fixes the issue before the SLA is at risk. The gap between the two is your buffer.

## Step 3: Instrument your platform and measure

Your observability stack should surface SLO misses, and trends heading towards them, before they turn into incidents. That means:

- **Metrics collection**: latency, error rate and throughput captured at every layer.
- **Alerting**: thresholds that fire as you approach an SLO boundary, not only once something has broken.
- **Dashboards**: a live view of platform health that engineers and stakeholders can read at a glance.

Tools vary by stack and scale, but the principle does not: you cannot improve what you do not measure.

## Step 4: Build a roadmap for improvement

Once you know where you stand, set out the sequence of work that gets you to where you want to be.

A roadmap usually spans several projects across technology and process, each with an owner, a timeline and an expected SLO improvement. Set intermediate targets so progress stays visible.

Avoid trying to fix everything at once. Pick the one or two SLIs with the biggest business impact and start there.

## Step 5: Execute, review and adjust

Review cadence matters. In our experience:

- **No more often than fortnightly**: changes need time to show up in your metrics.
- **No less often than quarterly**: longer gaps let drift compound.

Use different rhythms for different depths. A weekly look at dashboard trends is not the same as a monthly SLO review, which is not the same as a quarterly reassessment of the roadmap.

## A note on SRE

Some readers will recognise site reliability engineering (SRE) principles in this framework. That is deliberate, but it is not textbook SRE.

SRE was coined at Google by Ben Treynor Sloss and has since been adopted by large organisations with dedicated SRE teams, mature tooling and the budget to match. The usual saying applies: *you are not Google*.

Standard SRE practice is excellent and largely right, but it is designed for a scale most companies never reach. Adapting it takes experience that smaller teams rarely have in-house.

At Vigesimal we call our approach **agile SRE**: the core principles applied in proportion to your scale, your team and your current maturity. The goal is the same, a platform that reliably supports the business. The path is set by where you actually are.

*Which of these steps would be most useful to explore in more depth? [Tell us](https://vigesimal.tech/contact). We would like to hear from you.*

---

Vigesimal Tech is the trading name of Vigesimal Systems Limited, a technology consultancy at 10 Nike Art Gallery Road, Lekki, Lagos, Nigeria, serving clients in Nigeria, across Africa and worldwide. Email info@vigesimal.tech, or book a free 30-minute consultation at https://vigesimal.tech/contact. Every page of this site is listed for AI agents at https://vigesimal.tech/llms.txt