Skip to content

Run / Reliability & Observability

Know it broke before your customers do.

Instrumentation, incident response and capacity work for systems where downtime is measured in lost trust as well as lost revenue.

Start a project

Customers are the monitoring

You find out about outages from support tickets, which means the clock started before you did.

Nobody can say why it broke

Logs exist somewhere, traces do not, and every incident review ends in a plausible theory rather than an answer.

The bill grows faster than the traffic

Cloud spend rising with no clear line back to what is causing it.

What we do

  • 01Instrumentation and tracingStructured logs, metrics and distributed traces that answer questions rather than store text.
  • 02Alerting that means somethingAlerts tied to user-visible symptoms, so paging someone is justified.
  • 03Incident responseOn-call structure, runbooks and blameless review that produces changes.
  • 04Capacity and cost engineeringFinding the spend that buys nothing, without pretending performance is free.
  • 05Infrastructure as codeEnvironments that are reproducible rather than remembered.
  • 06Resilience testingBreaking it deliberately, in daylight, with a rollback ready.

How we work

  1. 01

    Assess

    1–2 weeks

    What is running, what is watched, and what would happen at 3am today.

  2. 02

    Instrument

    2–6 weeks

    Traces, metrics and alerts wired to real symptoms.

  3. 03

    Rehearse

    1 week

    A deliberate failure, run as a drill, with the team on the call.

  4. 04

    Run

    Ongoing

    Retained on-call cover, or handover to your team with the runbooks written.

Screenshot placeholder

Marketplace settlement pipeline

The challenge
A payout pipeline where a silent failure meant vendors were not paid and nobody knew until they asked.
The approach
Traced the settlement path end to end, alerted on the business symptom rather than the process, and added a reconciliation check that fails loudly.
The result
Failures surface as an alert with the failing transfer attached, before a vendor has cause to chase.

Questions we get asked

Do you host our infrastructure?

No. We design, instrument and operate what runs on your accounts. Reselling hosting is not a business we want.

Which tools do you use?

OpenTelemetry for instrumentation so you are not locked to a vendor, then whichever backend fits your budget and scale.

Can you carry the pager?

Yes, under a retained arrangement with agreed hours and escalation. We will not pretend to cover 24/7 with a small team unless it is staffed to.

What if our system is already on fire?

Then we start with stabilisation and instrumentation, and do the architecture conversation once the alerts are quiet.

Will this reduce our cloud bill?

Often, but we will not promise a number before looking. Cost work that degrades reliability is not a saving.

Tell us what you’re building.

Start a project