Application Metrics, Done Properly
Numeric measurements of application behavior, such as request rates, error rates and queue depths.
Marcus Adeyemi
At a glance
- Types counters, gauges and histograms serve different purposes
- Cardinality too many label combinations makes metrics expensive
- Dashboards surface the metrics that matter
- Alerting should be based on user-visible symptoms
Why it matters
Why it matters: Metrics show trends and trigger alerts, while logs explain individual events, and teams need both.
Best practice
- Track request rate, error rate and duration
- Measure queue depth and job failures
- Keep label cardinality under control
- Alert on symptoms, not every metric
- Review dashboards after incidents
Common pitfalls
Watch out for:
- Metrics with unbounded labels
- Dashboards nobody reads
- Alerts on every deviation
- Measuring only infrastructure, not the application
When to call in a specialist
Bottom line Bring in help when incidents are diagnosed by guesswork.
Where this comes from
- Microsoft Learn — Monitoring and diagnostics guidance
- OWASP — Logging Cheat Sheet
The figures and practices above come from the sources listed.
Working on something like this?
We take on Web Design & Development work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.
Where to go next
Spotted something wrong? Report an error on this page. We correct on the page and say what changed.
