Data & Cloud
Your platform, watched around the clock
SLA-backed operations for the platforms we build — and the ones we didn't.
The platform is live; now someone has to watch it — patches, certificates, backups, 2 a.m. alerts, and the creeping drift that turns healthy systems fragile. That someone shouldn't be your product team's weekend.
- Uptime backed by SLA, not luck
- Security patching that never slips
- A monthly report your management actually reads
Capabilities
What the work actually involves
24×7 monitoring & response
Alerting tuned to signal, on-call rotations, and incident response with named SLAs.
Patch & lifecycle management
OS, dependency, and certificate hygiene on schedule — the unglamorous work that prevents breaches.
Backup & recovery assurance
Backups that run, restores that are actually tested, and evidence for your auditors.
Performance & cost reviews
Quarterly architecture and FinOps passes so the estate improves instead of just persisting.
Escalation to builders
When support needs engineering, the people who build platforms are one desk away.
Runbooks and knowledge transfer
Documented procedures for the things that recur, written so your own team can execute them — support that cannot be taken back in-house is a dependency, not a service.
Capacity and scaling reviews
Headroom checked against the growth actually happening rather than the plan, ahead of the seasonal peak rather than during it.
Deliverables
What you are handed.
Yours to keep, and written so another team could pick them up.
An SLA with defined severities
What counts as P1, what the response time is, and what happens when we miss it.
On-call held by people who know the system
Usually the ones who built it.
Monthly operational reporting
Uptime, incidents, spend and the trend on each — not a ticket count.
Continuous cost optimisation
Reviewed quarterly, because a cloud bill left alone only goes one way.
We do not publish prices — scope drives them. Everything else, here.
- Starts with
- A handover period running alongside your current arrangement
- Typical duration
- Ongoing, three-month minimum
- Who you get
- An SRE pod with named primary and secondary on-call
- Commercial model
- Monthly retainer by environment count and cover level
How to decide
What the answer depends on.
Two sets of conditions. Read both against your own situation — most organisations recognise themselves in one column within a sentence or two.
This is the right call when
- You have a platform in production and no team to run it at night.
- Cloud spend is growing faster than usage and nobody owns it.
- You need a documented support position for a client or an auditor.
A different approach fits better when
- Support has to begin on an unfamiliar codebase with no handover period.
- Business-hours cover is enough — you can do that in-house more cheaply.
- No monitoring exists and no appetite to add any.
Before you ask
Questions about managed cloud support
Sectors
Where this comes up most.
The regulatory context and the systems already in the building change the build. Each sector page says how.
Next step
Bring us the problem. We will bring the architecture.
A discovery call takes forty-five minutes. You leave with our read on the problem, the shape of the system we would propose, and a straight answer on whether we are the right team for it.
- No sales deck
- An engineer on the call, not an account manager
- NDA before you share anything