Managed data platform operations
Monitoring, disaster recovery drills, upgrades and support for the whole data platform under agreed service levels, with 24/7 cover where you need it and your own team trained to take over.
A data platform is judged on its worst day, not its launch
A feed that stops silently at 2 a.m. means a regulatory return built on yesterday's data. A database that fails over badly means a morning without customer service. A vector index that stops refreshing means an assistant that quietly answers from last month. None of these show up at go-live; all of them show up in the first year.
We run the platform the way we built it: every component monitored for health and for freshness, every alert with an owner and a runbook, recovery rehearsed on a schedule, upgrades planned and tested, and service levels reported monthly. Your team works alongside ours from the first day, and takes over as much as you want, when you want.
When it fits
01
The platform is live and the project team has left
The build was delivered, and now a small team has to keep pipelines, databases, Kafka and the index running.
02
Failures are found by the business
A late feed or a stale dashboard is noticed by the people who use it, not by monitoring.
03
Upgrades are deferred
Kafka, PostgreSQL and OpenShift versions are falling out of support because every upgrade feels risky.
04
Recovery is a document
The disaster recovery plan exists on paper, and nobody has run it with the applications live.
What we do
Monitoring and alerting
Health, capacity and freshness for every pipeline, topic, database, table and index, with alerts that name an owner and a runbook.
Incident response
Engineers who know your platform on call, with agreed response times, and a review after every incident that changes something.
Disaster recovery drills
Scheduled failover and failback of databases, Kafka and the lakehouse to the second site, measured against the recovery objectives and reported.
Upgrades and patching
A tested upgrade path for OpenShift, Kafka, PostgreSQL, Trino, Spark and the indexes, rehearsed in staging before production.
Capacity and cost
Growth tracked against the sizing, storage and compute added before they run out, and licence and hardware spend reported.
Knowledge transfer
Runbooks, pairing and training so your engineers take over the platform in stages, with us behind them.
The operating loop
Monitor, respond, rehearse, report
Monitoring watches health and freshness. An alert goes to an engineer with a runbook and is resolved and reviewed. Recovery is rehearsed on a schedule rather than tested by an outage. And every month the service levels are reported, so the platform's reliability is a number you can see, not a feeling.
- Monitoring
- Health, capacity and data freshness for every component, on one set of dashboards.
- Alerts and response
- An alert with an owner and a runbook, resolved within agreed times and reviewed afterwards.
- Disaster recovery drills
- Scheduled failover and failback to the second site, with the applications running.
- Reporting against service levels
- Availability, freshness, recovery time and incidents, reported every month.
How managed operations start
01
Take stock
Review the platform, its monitoring, backups, documentation and the service levels the business needs.
02
Instrument and document
Close the gaps in monitoring and runbooks, agree alert routing and on-call, and set the drill and upgrade calendar.
03
Run together
Our engineers and yours operate the platform side by side, with the first disaster recovery drill in the first quarter.
04
Report and hand over
Report service levels monthly, review incidents and capacity, and move responsibilities to your team as agreed.
What you get
- Monitoring and alerting for every component, including data freshness
- Runbooks for every alert and procedure, kept current
- On-call engineers with agreed response times, 24/7 where required
- A disaster recovery drill each period, with its report and fixes
- Tested upgrades on a published calendar
- A monthly service report covering availability, freshness, incidents, capacity and cost
What we run it with
The same observability stack for the whole platform, from the cluster to the freshness of a table.
Observability
- Prometheus
- Grafana
- Loki
- OpenTelemetry
- Tempo
- Alertmanager
Platform operations
- Red Hat OpenShift
- Argo CD
- Ansible
- Streams for Apache Kafka console
- Crunchy Postgres for Kubernetes
- OpenMetadata
Questions about managed operations
Can you support a platform you did not build?
Yes. We start with a review of what is there, close the gaps in monitoring and documentation, and run it alongside your team. Where a component is unsupported or unsafe, we say so and plan the change.
Do you offer 24/7 cover?
Yes, with engineers in Dhaka who know your platform. Response times and escalation paths are agreed in the service levels, and we report against them every month.
What does a disaster recovery drill involve?
A scheduled, announced switch of production to the second site and back, with the applications running, measured against the recovery objectives. Each drill produces a report and a list of fixes, which is the point of doing it.
Can our team take over completely?
Yes, and we plan for it. Responsibilities move to your engineers in stages as they are ready, and we stay behind them for as long as you want.
The labs our engineers train onRun the platform under service levels
Tell us what you run and what keeps you up at night. We'll propose the cover you need, from expert help for your own team to fully managed operations.