Site reliability engineer Applications that stay up, and changes that can be undone.

For teams that hear about problems from their users, or whose deploys feel like a held breath: monitors, SLOs and alerts in code beside the infrastructure, a way back for every change, and applications kept healthy in production together with their developers.

Get in touch The tools behind it

Four parts of reliability work.

Reliability kept in the same code and the same reviews as everything else.

Observability as code

Monitors and SLOs, reviewed like code.

Monitors, SLOs and log pipelines in Datadog, CloudWatch alarms and dashboards, and DNS health checks, all in Terraform: alerts defined next to the service they watch, and changed through a pull request.

Reliability and observability skills
Change management

Every change planned with a way back.

A risky change gets a written plan: what moves, in what order, how we will know it worked and how to roll it back. Infrastructure changes show their plan in review before they apply, and a release that goes wrong is rolled back rather than patched live.

Release skills
Incident triage

Triage that starts from the evidence.

When something breaks: the logs, the metrics and the latest changes first, then the fix, then a note on what to watch next time. Cloud provider health notices get the same treatment.

Reliability and observability skills
With the developers

Running the application, not only the servers.

I work with the developers on what their applications need in production: queues, caches, search, timeouts and health checks, whatever language the application is written in. Dependencies stay current with Dependabot, so a security fix arrives as a reviewed pull request.

Ways of working