# Site reliability engineering for high-traffic systems

Kitecorp brings site reliability engineering to products that cannot fail in public: service level objectives the product team accepts, observability that explains incidents instead of announcing them, an on-call rotation people can sustain, and capacity plans written before the launch rather than after it.

Canonical: https://kitecorp.org/services/sre-consulting

## What does an SRE engagement deliver?

Service level objectives for the user journeys that matter, with the error budget each one allows and the policy for what happens when the budget runs out. Observability that answers the on-call engineer's first three questions (what broke, since when, for whom) from one screen. An alerting set reduced to the pages that need a human now, with everything else routed to a dashboard or a ticket. An on-call rotation with runbooks for every alert that can page. Capacity plans for the next launch, built from load tests and real traffic shapes. And a review practice for incidents that produces fixes instead of blame.

## How do we set SLOs a product team accepts?

By starting from the user, not the server. An SLO on CPU utilisation means nothing to a product manager; an SLO that says "99.9% of uploads complete within 10 seconds, measured over 30 days" is a promise they can sell and a budget they can spend. We pick two or three journeys, measure what the system does today, and set the first targets at or slightly above current performance. Targets go up when the budget has been unspent for a quarter; they never start at five nines because a slide said so.

## What does on-call look like afterwards?

Sustainable. A rotation of at least four people, pages only for alerts that have a runbook and a known action, and a weekly review of every page to decide whether it should exist. The practices we set up came from running consumer services at carrier scale, where a page at three in the morning that nobody could act on was the most expensive alert of all.

## How do we plan capacity for a launch?

With numbers from the system itself. We take the traffic shape of a previous launch or a comparable product, scale it to the forecast with headroom, and load test the real stack to the point where it breaks, so the breaking point is a known number rather than a surprise. The plan then names what scales automatically, what must be pre-provisioned, and the signal that triggers each step on launch day. The telecom work behind this practice is described in the [telecom industry page](/industries/telecom).

## How does an engagement run?

A discovery call to understand the product, the traffic and what has hurt recently. An assessment of the current signals, alerts and on-call load, with the first SLOs and the alert reductions proposed. The implementation with your team: dashboards, alert rules, runbooks, load tests. A handover and a few weeks of joint on-call review while the practices settle. Pricing follows the discovery call, once we know the scope.

## Frequently asked questions

### Do we need a dedicated SRE team?

Not at first. Most products need the practices (SLOs, error budgets, blameless reviews, capacity planning) long before they need a separate team. We set up the practices with the engineers you have.

### Which observability stack do you use?

Prometheus and Grafana for metrics and dashboards, OpenTelemetry for traces, and the cloud's own logging or a managed service for logs. We work with Datadog or similar where a client already runs it.

### What does an incident review look like afterwards?

A written timeline, the contributing causes, the action items with owners, and no names in the blame column. The review is for the system, not the person on call.

### Do you work with our existing team?

Yes. Every engagement is delivered with your engineers and ends with a handover, runbooks and alerts they own.

### How do we start?

Send a message through the contact page. We schedule a discovery call, agree the scope, and pricing follows what we find.

## How to start

Send a message at https://kitecorp.org/contact or email admin@kitelang.cloud. Pricing follows a discovery call.