Senior SRE reliability without building a platform team
A company running its own product needs someone to define what «working» means, measure it, cut the alert noise and turn every incident into something that does not happen the same way twice. That is SRE work, and you do not need a platform team to have it: we provide it on a subscription, with senior engineers, written objectives and deliverables that stay in your repository. We always start with a diagnostic, and if it turns out you do not need an ongoing service, we say so.
Last updated:
Does this sound familiar?
If three or more of these ring true, the problem is not your tooling.
- Alerts fire at night, almost always for nothing, and nobody looks at them any more.
- Incidents are solved from memory by the same person, and nothing is written down for next time.
- Nobody can say whether the service meets what the contract promises, because nothing is measured.
- The observability bill grows faster than the traffic, and it is not clear how much of that data anyone ever looks at.
- A deployment takes an afternoon and needs the person who built it in the room.
- Backups exist, but nobody has ever actually tried restoring one.
- The auditor asks for the dependency map and the recovery tests, and it has to be put together by hand every time.
- You have been hiring a senior SRE for months and the candidates who apply cost what half a team costs.
Why this is a problem now
A senior SRE is scarce and expensive
Reliability engineering is a profile with far less supply than demand, and that shows in hiring times and in salaries. For many companies the problem is not the budget: it is that one person does not cover a function that needs continuity, and that a months-long hiring process leaves the problem open while it runs.
Observability has got expensive
Observability platforms bill by volume ingested, and the volume grows on its own: more services, more containers, more labels. The typical reaction is to cut retention and switch off traces, which is exactly what you need on the day of the hard investigation. What actually lowers the bill is not sending what nobody looks at, and for that you have to know what is looked at.
The regulation now asks you to prove it
DORA (Regulation EU 2022/2554) has applied since 17 January 2025 to the financial sector and its technology providers, and NIS2 (Directive EU 2022/2555) considerably widens the set of entities covered and tightens incident notification. Both ask for the same thing underneath: incident management with criteria, resilience testing that actually happens and evidence you can produce. That is no longer good practice, it is a requirement with a date on it.
What changes if it is done well
Nothing spectacular, and that is the signal: fewer pages at night, incidents resolved without one particular person in the room, deployments that are not frightening, and a written answer when a large customer asks how much your service can take.
The five services
They can be contracted separately. Most people start with whichever has the deadline or the pain attached.
Fractional SRE
A reliability team on a subscription: SLOs, actionable alerting, on-call, incident management and production readiness, with senior engineers and deliverables that stay with you.
Observability cost
We audit what telemetry you generate, what is actually looked at and how much of the bill pays for data nobody queries. With a plan to filter, sample and route before sending.
DORA and NIS2 resilience
The technical side of DORA and NIS2: incident classification and notification, resilience and recovery testing, a dependency map and evidence that collects itself.
European sovereign cloud
Leaving a non-European hyperscaler without getting locked into the next one: assessment, architecture and migration to Exoscale, STACKIT or OVHcloud with Kubernetes and infrastructure as code.
AI-assisted operations
Agentic runbooks and incident copilots connected over MCP to Kubernetes, logs and metrics, deployed inside your environment so operational data does not leave it.
How we start
Diagnostic call
Half an hour: what you run in production, what breaks and what hurts. No sales deck.
A written proposal
What we would do, in what order, with which deliverables and over what timescale. And what we would not do yet.
A first bounded piece of work
An alert review, a set of SLOs or an observability audit. Something that finishes and can be judged.
Ongoing service, if it makes sense
A subscription priced on scope and service levels. If the bounded work was enough, it stops there.
A 30-minute diagnostic call
Half an hour with senior engineers to go through what you run in production, what breaks and what hurts. At the end we tell you what we would do first and whether it needs more than an afternoon of work. No sales deck, no commitment.
If the conversation concludes that you do not need an ongoing service, we say so there and then. We prefer that to a subscription that improves nothing.
Frequently asked questions
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.
Do you sign a non-disclosure agreement?
Yes, if you want one, and nothing we see is used as an example anywhere without written permission. Access is requested at the minimum needed and documented.
What happens if we stop?
You keep everything: the SLOs, the runbooks, the infrastructure code in your repository, the dashboards and the documentation. There is no lock-in and nothing that only we know.
Let us talk about what you run in production
Which services, what breaks, what you are being asked for. We reply within 24 working hours with a first assessment and what we would do first.
or write to us at info@esdis.es