Reliability and observability at Gridware: how an observability overhaul dramatically cut production incidents
I’m Muhammad Anas. As Engineering Manager at Gridware I introduced observability and incident management practices across the core grid-monitoring platforms. Dashboards started finding problems before customers did, production incidents became dramatically rarer, and on-call went from chaotic to calm.
The challenge
Gridware builds grid-monitoring technology, and the cloud-native, mobile-first platforms my teams ran sat in the critical path for external customers. As those platforms scaled, production issues were too often discovered the worst possible way: a customer noticed before our dashboards did.
Each incident pulled engineers off the roadmap and into firefighting. Nobody had shared visibility into what the systems were actually doing, so diagnosis was slow and fixes were stressful. Reliability felt like luck. It wasn’t yet something the team controlled.
My role
As Engineering Manager, placed with Gridware through Remotebase and working remotely, I owned both delivery and production stability across critical systems. That meant designing serverless solutions on AWS using microservices and SOA with NestJS, streamlining delivery with GraphQL, AWS Amplify, and CI/CD pipelines, and working directly with C-level stakeholders and external customers on roadmap alignment. Incident management was mine end to end. If production broke, the buck stopped with me.
The approach
- Instrument firstBefore changing any process, we made the systems observable. Metrics, logs, and traces flowed from the core platforms into dashboards the whole team could read, built with the usual tools in this space: Datadog, Grafana, Prometheus, Sentry, and CloudWatch. You can’t fix what you can’t see.
- Define what “healthy” meansWe set SLO-style thresholds for the things users actually feel, and wired alerting to user impact rather than raw noise. A page meant something real was wrong, and quiet meant the platforms were genuinely fine.
- Run incidents as a structured processWe introduced structured incident command: clear severity levels, a single owner per incident, predictable communication, and blameless post-incident reviews. Every failure turned into a concrete improvement rather than a scar.
- Harden the pipelineReliability also depends on how fast you can ship a fix. CI/CD discipline across the GraphQL and AWS Amplify stack meant remediations and preventative work rolled out quickly and safely, with the serverless architecture keeping blast radius small.
The results
- Dramatically fewer production incidents across the core platforms. The firefighting that had been eating roadmap time largely disappeared.
- Issues caught before customers noticed. Dashboards and impact-based alerts surfaced problems while they were still cheap to fix.
- A real learning loop. Blameless post-incident reviews fed directly into the backlog, so each incident made the system stronger.
- Stability across critical systems. Calm, structured on-call and a reliability record C-level stakeholders and customers could trust.
What made it work
Observability is a product decision. We treated instrumentation, dashboards, and alerting as part of the platform itself. They were planned, owned, and prioritized like any other feature, long before the next outage forced the issue.
SLOs turn reliability debates into data. Once “healthy” was defined in terms of user impact, conversations with C-level stakeholders stopped being about anecdotes and started being about thresholds. That made it far easier to balance roadmap work against reliability work.
The goal is boring on-call. Structure, severity levels, and blameless reviews exist so that pages are rare, response is calm, and engineers keep their energy for building. Boring on-call is what a reliable platform feels like from the inside.
“Anas’ leadership and commitment to getting the job done was a force that always moved the needle for us.”
Is reliability slowing your roadmap?
I help product organizations make production stability a managed outcome, through observability, SLOs, and incident management practices that let teams ship fast without fear. I do this as an engineering leader, fractional CTO, or engineering leadership consultant.