How the workshops actually work
This isn't just theory. You spend time building, testing, fixing things that break, and learning what happens when systems run under pressure. Each workshop follows a sequence designed to get you past the "I think I understand" stage into the "I know this works because I've done it" territory.

Three phases that build on each other
Each phase introduces new layers of complexity. You start with basic instrumentation, move into analysis, and finish by handling real-world scenarios where things go sideways.
Setting up the instrumentation
Before you can optimize anything, you need to see what's happening. This phase covers setting up metrics, logs, and traces without drowning in data noise.
- Choosing what to measure and why
- Configuring APM tools without breaking production
- Creating dashboards that show actual problems
- Avoiding common monitoring traps
Finding the bottlenecks
Now that you can see what's happening, you learn how to interpret the data. This is where most people get stuck—knowing what the numbers mean and where to look next.
- Reading flame graphs and trace waterfalls
- Identifying CPU vs I/O vs memory issues
- Database query analysis techniques
- Network latency investigation methods
Fixing things under load
The final phase puts everything together. You work through scenarios where the system is struggling and you need to figure out why and fix it without making things worse.
- Load testing and capacity planning
- Making optimization decisions with trade-offs
- Implementing changes without breaking stability
- Documenting findings for future reference
What previous participants say
I went through three workshops last year. The first one made me realize how much I didn't know about what my application was actually doing in production. By the third workshop, I was the person on my team who could look at a trace and tell you exactly which service was causing the slowdown.
The setup phase seemed basic at first, but it forced me to think about what metrics actually matter. That alone changed how I approach any new service I deploy now.