Monitoring & Observability

It matters less than the discipline around it, and the cheapest good answer is often the one already included with your cloud provider plus an error tracker. We commonly use Grafana for metrics and dashboards and Sentry for application errors, both of which have workable hosted and self-hosted options. We would rather spend the budget on defining fewer, better alerts than on a platform whose value depends on someone curating it.

Few enough that every one is read. For a typical single application, a working set is often under a dozen alerts that can wake someone, covering availability, error rate, latency, failed background jobs and the handful of dependencies whose failure stops the service. Everything else belongs on a dashboard or in a weekly review, not in a notification.

Only within limits worth stating plainly. We can hold first-line response for infrastructure and platform failures under a support agreement, with hours and response commitments agreed with you in writing. We cannot make judgement calls that require knowledge of your business — whether to halt a promotion, contact a regulator or accept degraded service during a busy period — and those escalations need a named person on your side who can decide.

Metrics and structured logging have a negligible effect at the volumes most applications run at. Distributed tracing is heavier, which is why we sample it rather than capture every request, and we measure the overhead in staging before enabling it in production. If instrumentation ever costs more than the insight it provides, it should be removed, and we will tell you when we think that line has been crossed.