Observability before you need it, not after the outage
The dashboards you wish you had are the ones to build now.
Observability almost always gets built reactively — after an outage, in the exhausted aftermath, someone adds the metric that would have caught it three hours earlier. That's better than nothing, but it means the system is always one incident behind on the visibility it actually needs.
Instrument as part of the feature, not after
The alternative is treating observability as part of building the feature, not a follow-up task: what would tell us this is broken before a customer does, what would tell us why, and is that instrumented before this ships, not after it breaks.
Metrics, logs and traces answer different questions
Metrics tell you something's wrong, logs tell you what happened, and traces tell you where in a distributed system it happened — treating all three as one undifferentiated 'monitoring' effort tends to leave real gaps in whichever one got the least attention.
The five-minute test
The test worth applying: if this broke at 2 a.m., would the on-call engineer know what happened within five minutes, or would they be guessing until a customer explained it to them. If it's the second one, that's the gap to close before the outage, not during it.
- Observability built after an outage means you're always one incident behind.
- Instrument for 'how would we know this broke' as part of building the feature.
- If on-call can't diagnose an issue in five minutes, that's a gap to close now.
Picking a cloud provider without the marketing noise
HAVE A PRODUCT IN MIND?
Tell us what you're building and where you need engineering support.