Why I Started OpsMastery Summit

Most of the outages I have worked started the same way. No alert fired. A customer wrote in, then another, and somebody pasted a ticket into the incident channel. Twenty minutes later we were all on a bridge, staring at dashboards that had been green the whole time.

That is not a tooling problem. Everyone on that bridge had tools. We had metrics, logs, and a tracing rollout that was one twentieth done. What we did not have was a practice. Nobody had decided what a healthy checkout looks like from the customer's side, so nothing was watching for it.

I am passionate about observability because I have seen the other version. An engineer gets paged on a leading indicator, a queue backing up or a connection pool trending toward saturation, and fixes it before a single customer notices. Quiet. Boring. No postmortem. That is the goal, and it is far rarer than it should be.

I organized Salt Lake City DevOpsDays for five years. The format is simple. Practitioners give talks, open spaces build the agenda in the room, and the best conversations happen in the hallway. The moments I remember are never the polished slides. They are someone standing up and saying, here is what broke, and here is what we got wrong.

Those years convinced me of two things. People in operations are hungry to learn from each other, and they will show up for it. They also deserve more time than a hallway gives them.

DevOpsDays is great at starting conversations. I wanted a place where those conversations get a full half day and a keyboard.

OpsMastery Summit is two and a half days in Salt Lake City, planned for May 2027. It is for the people who keep SaaS running: SRE, platform, incident, and NOC teams, and the leaders who answer for them.

The first day is hands-on workshops, one per track. Then two days of keynotes, technical deep dives, and panels. The three tracks are general observability, AI observability, and building visible software with OpenTelemetry.

A few rules I'm holding myself to. War stories over vendor pitches. Speakers who have run this in production. Fewer slides about tools, more about the decisions behind them.

Because everything else in operations sits on top of it. You cannot run a good incident if you cannot see. You cannot set a meaningful SLO without honest indicators. You cannot trust AI-assisted operations built on data nobody instrumented.

Monitoring tells you whether a system is up. Observability tells you why it behaves the way it does, and whether the customer is okay. Later editions will go wider into the rest of operations. This one starts at the foundation.

I live here, and I know what this community can do when you give it a room.