BLUEHARBOURD2
Book an intro call

Depth 06 · Service line

Managed services

Managed services means a company hands the ongoing operation of its software and infrastructure to an outside team under a contract that states what is watched, who responds, how fast and what counts as done. The work is mostly routine: monitoring, releases, patching and backups. It exists so that problems are found by the people responsible before customers find them.

Inside this line

Three sub-services: monitoring and support, release operations and infrastructure care.

Input
Access to the systems in scope, the existing documentation however incomplete, and a named contact on your side for decisions.
Method
We start with a handover period where we document what exists, set up monitoring and run through one incident and one release together. Only then does the agreed response arrangement start.
Deliverable
An operating agreement listing systems, hours and response arrangements, a runbook for each system, and a monthly report of incidents, changes and open risks.
Measured by
Response and resolution times against the targets in your contract, uptime recorded by monitoring, and the count of incidents that repeated a known cause.

Level 3 · 01

Monitoring and support

Monitoring and support is the work of watching production systems around agreed hours, raising an alert when something breaks or starts to degrade, and having a named person respond. Support covers the human side: someone to report a problem to, a record of each incident, and a follow up so the same cause does not return.

Inside it

  • Uptime and synthetic journey checks
  • Error and log alerting
  • Severity levels defined in the contract
  • Incident log and written reviews
  • Monthly report

Measured by Acknowledgement and resolution times against the contracted targets, alerts that needed no action, and incidents with a repeated cause.

Monitoring and support, full page

Level 3 · 02

Release operations

Release operations is the process that moves a code change from a developer's branch into production, safely and on repeat. It covers the build pipeline, the checks a change must pass, how a release reaches users and how it is rolled back when something goes wrong.

Inside it

  • Continuous integration and build pipeline
  • Automated test and security checks
  • Staged or gradual rollouts
  • Tested rollback
  • Release log and approvals

Measured by The four DORA delivery measures recorded from your own pipeline (industry benchmark: the annual State of DevOps report from DORA publishes reference ranges for each).

Release operations, full page

Level 3 · 03

Infrastructure care

Infrastructure care is the scheduled maintenance of the servers, cloud accounts, databases and networks a product runs on. It covers patching, backups that are restored in tests, certificate and dependency renewals, access reviews and cost checks. None of it is visible when done well, which is why it is often skipped.

Inside it

  • Operating system and dependency patching
  • Backups with scheduled restore tests
  • Certificate and domain renewals
  • Access reviews
  • Cloud cost review

Measured by Patches applied within the window set in your contract, backup restores that succeeded, and expired certificates or credentials, which should be zero.

Infrastructure care, full page

Where this applies

Who this is for: Engineering leads running production systems with a small team, where releases, alerts and patching land on whoever is free that day.

Sectors this line is set up for, not a list of clients.

B2B softwareIND 02
Release and incident routines for teams without a dedicated operations engineer.
EcommerceIND 05
Monitoring of checkout, payments and stock sync, with alerts routed to a named person.
Payments and fintechIND 01
Change records and incident logs kept in a form an auditor can read.

Shape of the work

01Change02Review03Release04Observe05Respond and record
Release and response cycle: change, review, release, observe, and on an alert respond and record, which feeds the next change.

What you get

  • 06.1 · Monitoring and supportLive monitoring, an incident log, and a short written review after each serious incident.
  • 06.2 · Release operationsA documented release pipeline in your accounts, a rollback procedure that has been tested, and a release log.
  • 06.3 · Infrastructure careA maintenance calendar, a backup restore record, an access review record and a monthly cost note.

What we work with

Data
PostgreSQL · pgvector · Supabase · Redis · dbt · BigQuery
Automation
n8n · scheduled jobs · event driven triggers
Cloud and delivery
Vercel · Cloudflare · AWS · Google Cloud · Docker · Terraform · GitHub Actions
Quality and observability
Playwright · Sentry · uptime monitoring · structured logging · error budgets
Security and access
SSO and SAML · secret managers · dependency scanning · SBOM · least privilege reviews

These are the tools we work with, not partnerships, certifications or resale agreements.

How this fits the other lines

When this is not the right line

If you need someone on site, or a guaranteed answer within minutes at any hour, we are the wrong supplier. If your system changes every day under active development, a build engagement fits better than a support agreement.

Questions about this line

What do you need from us to take over operations?
Admin access to hosting, the repository and the monitoring you already run, plus any runbooks that exist. Where none exist, writing them is the first deliverable, and we accept an on call rota only after they are written.
What response times do you offer?
We do not publish standard response times. They are agreed per contract, because a payment system and an internal wiki need different answers. The contract states, for each severity level, how quickly someone acknowledges the issue, how quickly work starts and during which hours.
What is the difference between response time and resolution time?
Response time is how long it takes for a named engineer to acknowledge an incident and start working on it. Resolution time is how long until the service works again. Contracts that quote only response time say little about when the problem is actually fixed, so ours state both.
Can we take operations back in house later?
Yes, and the work is set up for that from the start. Runbooks, configuration and access records stay in your accounts and repositories, so a handover back to your team is a documented step rather than a rescue.

Describe what runs in production

List the systems you run and what happens today when one fails at night. We reply with the gaps we would close first.

Describe production

An email exchange first, no call needed.