Self-healing infrastructure plus engineers you can actually talk to.

Run engagements typically start when something has broken — or when the founder realised what would happen if it did.

1. Your team is the on-call rota and it's burning them out.

   We take the pager. Real on-call rotation, real escalation policy, real handover from the people who currently can't take a Saturday off.

2. You had an incident and the postmortem never happened.

   We run it properly: facts, timeline, root cause, the small handful of changes that actually prevent the next one. No blame theatre.

3. Your cloud bill is creeping and nobody owns it.

   Monthly cost review, named owner per workload, quarterly efficiency targets. No panicked cuts on the wrong line items.

4. You're launching enterprise customers and need a real status page.

   Real uptime tracking, customer-facing incident comms, a status page that's honest enough to build trust.

5. Dependencies and patches are slipping.

   We carry the dependency hygiene work — security patches, language upgrades, framework migrations — on a steady cadence so it never becomes a crisis.

The deliverable is, mostly, what doesn't happen: outages that don't take you down, bills that don't spike, dependencies that don't fall behind.

• 24/7 on-call coverage with named engineers. Real rotation, real response-time SLAs, a runbook for the top ten alerts that fire most often.
• Postmortems that change the system, not just the doc. Every incident gets a written postmortem and a small handful of follow-ups that actually ship.
• Monthly reliability reviews. SLOs, error budgets, what we improved, what we didn't — written, sent, read at your leadership meeting.
• Quarterly cost and capacity plans. Where the bill came from this quarter, what's coming next, what's up for renegotiation.
• Continuous small improvements. Security patches, dependency upgrades, observability tweaks, runbook updates — the work that never makes the roadmap but always pays back.
• A status page customers trust. Honest enough that an enterprise procurement team can sign off on it.

Run engagements are a monthly retainer scaled to your traffic, complexity, and the response-time SLAs your customers need. Usually two to four senior engineers and one SRE lead share the on-call rota and the improvement work.

If we built the system under a Build engagement we already have the context. If we're inheriting it, we run a structured two-week onboarding: shadow your current rota, write the runbooks that don't exist, then take over.

If a feature project pops up — a customer-driven build, a migration — we can spin a Build squad off the same lead, deliver, and fold the result back into Run. No vendor handoffs.