Fractional SRE: a reliability team on a subscription
Fractional SRE is a monthly service that covers the reliability engineering function without hiring a platform team: we define what it means for your service to work, measure it with SLOs and error budgets, keep only the alerts somebody can act on, build the on-call and incident process, and write the postmortems so that what was learned does not stay in a Slack thread. It is priced on scope and service levels, not on hours.
Last updated:
Reliability as a function, not as heroics
Who it is for
For scaleups and technology SMBs that already have a product in production and customers who notice when it goes down, but no platform team yet — and no reason to have one yet. Also for teams that do have one and are stretched: background reliability work is always the first thing to be postponed.
What it solves
Reliability depending on whether one particular person is available. With no measured objectives, every outage is argued over on feelings; with alerts nobody can act on, notifications get muted and the next one is missed; with no postmortems, the same failure comes back twice a year. None of that is fixed with more tooling: it is fixed with method, and method is what someone has to be working on every week.
Why hiring does not solve it
A senior SRE is a scarce profile, with the salary that implies, and one person does not cover a function that needs continuity. A months-long hiring process leaves the problem open while it runs, and the day that person leaves, everything that was not written down leaves with them.
The three changes you notice most
Measured objectives
SLIs and SLOs per service, with an error budget. You stop arguing about whether it is going well and start looking at how much failure budget is left this quarter.
Alerts somebody acts on
Every alert with an owner, a justified threshold and a runbook. The ones that do not pass that filter go: an alert nobody looks at is worse than no alert.
Incidents with a process
Severities, roles, communications and blameless postmortems. What is learned ends up in a runbook or a ticket, not in a conversation that is lost.
What the subscription includes
Reliability
A service catalogue with criticality, SLIs and SLOs per service with their error budget, and a monthly report on how much of that budget has been spent. That is what turns «the site felt slow» into a decision about whether this quarter goes on reliability or on features.
Alerting and on-call
A full review of the alert inventory, with the ones that are not actionable retired and the missing ones added. An on-call rota with escalation, severities and paging channels defined, and a runbook for every alert that stays.
Incidents
A written incident management process: classification, roles, internal and customer communications, and a postmortem template. We run the postmortems for the significant incidents and track the actions that come out of them, which is the part that normally never gets done.
Production readiness
A review of new services before they reach production, against our own checklist: resource limits, health probes, graceful degradation, dependencies, backups with a restore test and a rollback plan.
Delivery and automation
CI/CD improvements to make deploying boring: reproducible deployments, fast rollback, environments that match each other. GitOps with ArgoCD where there is Kubernetes, and infrastructure as code with Terraform in any case, so that what is running can be built again.
What «on-call» means here
We build and run your on-call process: the rota, the escalation, the severity levels, the paging and the runbooks, so that whoever takes the call at three in the morning knows what to do without waking anyone else. Our own response commitment is within 24 working hours, with contractual priority for critical work. If you need someone outside your organisation to pick up the phone at night, that is agreed separately and written into the contract: we do not advertise it as included, because it is not.
How it is contracted
A monthly subscription priced on scope and service levels, not on hours. What you sign is which services are in, which objectives we are working towards, what we hand over each month and how fast we respond — not a bucket of hours you have to spend before it expires. The fee depends on the number of services and how critical they are, so it comes out of the first conversation and is given as a fixed figure.
How we work
Diagnostic
Half an hour of conversation, then read access to whatever exists: dashboards, alerts, repositories and the incident history. We come out with an inventory and a priority list.
A plan for the first three months
In writing: what gets measured first, which alerts are retired, which process is built and in what order. Including what we are not touching yet, and why.
Implementation
We work inside your repository and your tooling, going through code review like any other team member. Nothing on systems of ours.
Operation and review
A monthly report on error budget, incidents and outstanding actions, and a quarterly review to adjust objectives. If an SLO is not helping anyone decide anything, it is changed or dropped.
Frequently asked questions
How many hours a month does it include?
It is not counted that way. What you sign is the scope — which services, what we hand over each month, how fast we respond — and the work needed to sustain it. A bucket of hours rewards spending them, not solving the problem.
Do you work in our repository or in one of yours?
In yours, with your tooling, going through code review. The runbooks, the infrastructure code and the dashboards stay where your team can maintain them.
What if our problem is cost rather than reliability?
Then start there: observability cost optimisation is a bounded piece of work with a report up front, and it does not need a subscription.
Does this replace our platform team?
No. If you have a team, we work with it: we bring the method, the reviews and the background work that never gets done because something more urgent always comes up. If you do not have one, we cover the function while there is not enough volume to hire for it, and we leave everything documented for the day there is.
Are you on call for us around the clock?
We do not advertise that, because it is not what we sell. We design and run your on-call process — rota, escalation, severities, runbooks — and our own response commitment is within 24 working hours, with contractual priority for critical work. Out-of-hours cover is agreed separately and written into the contract.
Which tools do you work with?
Kubernetes and Terraform for infrastructure, ArgoCD for GitOps, OpenTelemetry for telemetry, and Prometheus, Grafana, Loki and Tempo to look at it. Open, standard tooling on purpose: any engineer on the market can pick the work up, and you can stop working with us without having to redo it.
We do not run Kubernetes. Does this still apply?
Yes. SLOs, alerts with an owner, an incident process and postmortems work just as well on virtual machines, plain containers or your own servers. Kubernetes is a common tool, not a requirement, and we do not recommend it where there is no volume to justify it.
Do we have to change cloud provider to start?
No. Reliability work happens on what you already have, whether that is AWS, Azure, Google Cloud, a European provider or your own hardware. Migration is a separate service and only makes sense if there is a reason for it.
How long before we notice anything?
The noise goes first: an alert review usually shows results within the first few weeks, because a good share of what fires is not actionable. SLOs take longer, because they need measuring, and they are worth nothing until there are a few weeks of data behind them.
Tell us what you run in production
Which services, what breaks and what happens when it does. We reply within 24 working hours with a first assessment and what we would do first.
or write to us at info@esdis.es