Incident Management and SRE
Reduce blast radius, shorten recovery, clarify ownership, and strengthen the operating model around production systems.
I have spent years in the room when production breaks.
I help organisations reduce incident impact, improve SRE maturity, control cloud cost, and remove the conditions that make human mistakes expensive. Restoring service is the first job. Changing the system so the next failure hurts less is the work that follows.
Latest from me
A recent talk on FinOps for observability and keeping OpenSearch costs under control without giving up visibility.
Why The Incident Guy
The name comes from years spent handling production incidents: overnight pages, unclear ownership, noisy alerts, brittle releases, and postmortems that stopped too early. People started calling me when systems were down and the path back was unclear.
Over time the work widened. Incident response led into SRE practices, observability, architecture reviews, FinOps, DevOps, DevSecOps, and careful use of AIOps. The through-line stayed the same: keep customers safer when systems fail, and make failure cheaper to recover from.
Where I work with teams
FinOps and Cloud Cost
Make cloud spend visible, assign cost ownership, remove waste, and keep cost decisions from quietly eroding reliability.
DevOps and DevSecOps
Tighten delivery paths, put safety checks where they belong, and keep security inside the same workflow that ships changes.
AIOps and Automation
Use automation and signal correlation to cut noise and speed triage. Treat AIOps as decision support, not autonomous incident resolution.
Projects connected to this work
These sites publish the operating lessons that do not fit inside a single consulting engagement.
Vigiles
Built from lessons learned during incident response. Still improving, with a long road ahead.
OceanDB Pro
Independent OceanBase guides, migration notes, runbooks, and production lessons.
CloudArch Pro
Practical cloud architecture, FinOps, migration, reliability, and APAC infrastructure guidance.
Latest on X
Recent posts from @the_incidentguy.
We are now working on a ChatGPT plugin for OceanDB Pro. You will be able to ask questions about OceanBase architecture, migration, troubleshooting and operational practices directly inside ChatGPT. The answers will use the technical work we are doing while building the OceanBase knowledge base.
While building vigileshq.com, one requirement came up: how do we handle database incidents? The first database in this discussion was OceanBase. To build the connector, our team needed to understand how OceanBase works, including its architecture, operations, failure modes, migration, and troubleshooting. That work led to OceanDB Pro.
I built Vigiles because production teams keep starting from zero after every incident. The postmortem gets written. The root cause gets documented. It gets filed somewhere it will never be read. And then the next incident happens. Same scramble. Same war room.
Latest articles
We Deleted the ACK Node Pool, but the Subscription Charges Remained
We moved workloads to a new Alibaba Cloud ACK node pool and removed the old ones. Kubernetes looked fine. That was not enough to close the prepaid ECS commitments behind the old pools.
Human error is not a root cause
Human error describes what a person did before an incident. A useful investigation explains why the action made sense at the time and which controls allowed it to cause harm.
Cut MTTR without adding more alerts
Reduce MTTR by fixing ownership, incident context, rollback, runbooks and recovery paths instead of adding another noisy alert after each outage.