Monitoring and alerting
Metrics, logs and traces across the estate, with alerts tuned to things that actually matter rather than to everything that can be measured.
We build it, and we keep it running
The same platform, the same estate, the same code — with the pager on our side. Monitoring, updates, capacity, incident response and a service level you can hold us to.
Who a managed agreement is for
The common factor is not size. It is that the business is content and subscribers, and that nobody wants to build an infrastructure department to serve it.
- OTT platforms
- Services whose staff are commissioning, rights and marketing, with no platform team and no intention of hiring one.
- Broadcasters
- Organisations with a playout operation but no round-the-clock infrastructure rota for the streaming path.
- Enterprise network operators
- Teams that run corporate networks well but do not want video infrastructure added to that remit.
Owning the platform without staffing a platform team
Streaming infrastructure needs people who understand it at three in the morning during the one event that matters. Hiring that team is expensive, slow and — for most services — larger than the work justifies. A managed agreement is how you get the outcome without carrying the payroll.
What it is not is a black box. The estate stays in your repository and your accounts, declared in Terraform you can read. If the agreement ends, you are left with a running system and the code that produced it, not an outage and a migration project.
What's included
Incident response
An agreed response time, a documented escalation path, and a written post-incident review for anything that reaches your viewers.
Updates and patching
Security patching, dependency updates and platform upgrades applied through the same reviewed pipeline as everything else.
Capacity and cost
Capacity tracked against real growth, cloud spend reviewed against measured usage, and commitments recommended only once a baseline exists.
You can see everything
Access to the dashboards, the change log and the incident history. Managed does not mean opaque.
A clean way out
The estate is Terraform in your repository throughout. Ending the agreement is a handover, not a rebuild.
How a managed engagement runs
Discovery & HLD
Architecture, sizing and the service level the business actually needs — which is usually not the one it first asks for.
Build & onboard
The estate is built as code and instrumented before it carries traffic. Runbooks are written during delivery, not after.
Operate
Monitoring, patching, capacity and incident response on the agreed terms, with a regular service review.
Review & evolve
Cost, capacity and architecture revisited on a cadence, because a platform that is never revisited slowly becomes the wrong one.
What the agreement fixes
These are the terms a managed agreement names. The numbers against them are set per agreement, because an availability target is a consequence of the redundancy you have paid for — quoting one before the architecture exists would be quoting somebody else's estate.
| Term | How it is set |
|---|---|
| Availability target | Designed for and load tested against the delivered architecture, then written down |
| Severity definitions | Agreed in writing, with viewer-visible impact as the dividing line |
| Response target per severity | Per agreement, matched to the hours the service actually has to be up |
| Escalation path | Named people and a documented order, agreed before the first incident |
| Maintenance window | Scheduled outside your peak, which is the fixture list rather than a clock |
| Post-incident review | Written for anything that reached viewers, whether or not a target was missed |
| Service review cadence | Fixed interval covering capacity, cost and architecture |
| Exit notice and handover | Defined at signature, not negotiated at the end |
Is this the right engagement?
You want the service, not the team
Your business is content, subscribers and rights. Infrastructure is a means to that, and you would rather not build a department around it.
You already run platforms well
If you have an experienced platform team, implementation and handover is better value. We will say so rather than sell the larger engagement.
The things people ask first
Whose hardware and cloud account is it?
Yours. We operate your estate; we do not resell you capacity in ours. That keeps the exit clean and keeps the cost transparent.
What service level is realistic?
That depends on the architecture and on what you are willing to spend on redundancy. An honest availability target is designed for and tested, not written into a contract and hoped for.
What happens if we want to bring it in-house later?
Then it becomes the handover from the implementation engagement — runbooks, training, and a transition period. The code has been yours the whole time.
Talk about a managed agreement
What you want to run, the hours it has to be up, and how quickly somebody has to answer at three in the morning. That is where the conversation starts.