Observability before launch, not after

There is a reliable pattern in how monitoring gets adopted. A system launches with whatever the platform gives you by default. Something breaks and nobody notices for a day. That week, someone sets up proper alerting.

The work is identical either way. The only variable is whether you paid for the lesson first.

Three questions, before you ship

We treat these as launch blockers rather than nice-to-haves.

How will you know this is broken? Not "how would you investigate", but what actively tells you. If the answer is that a user will email, you do not have monitoring, you have customers doing monitoring for free.

How will you know it is broken for one customer? Aggregate health checks pass while a single tenant is completely broken, and that is the most common shape of a real incident. This usually requires error tracking keyed by tenant, which is a small amount of work done up front and an archaeology project done later.

How will you know it is slower than yesterday? Degradation is harder to notice than failure and is usually the earlier signal. Without a baseline you have nothing to compare against.

Log for the incident, not for the log

The instinct when adding logging is to add more of it. This makes the bad day worse, because now you are searching a haystack you built.

The useful discipline is to log with a shape. Structured logs with a request identifier that follows the whole path through your services. A consistent field for the tenant or user. Log levels that mean something specific, with error reserved for things a human should look at rather than for anything unexpected.

The question to ask of every log line: during an incident, what would I do differently because of this? If there is no answer, it is noise that will cost you both money in ingestion and time in searching.

Alerts should be things a person can act on

An alert that fires and gets acknowledged without action is worse than no alert, because it trains the team to acknowledge without action. That habit transfers directly to the alert that mattered.

A short set of alerts that always mean something beats broad coverage that mostly means nothing. Error rate above a real threshold. Latency at the ninety-ninth percentile crossing a line users would feel. A queue growing rather than draining. Spend per hour beyond expectation. Health check failing.

Anything else can be a dashboard, which is the right place for information you want available but do not want to be woken by.

The cheapest version is still worth it

If budget or time is the objection, the minimum viable version is genuinely small: structured logs with a correlation identifier, one error tracker, five alerts pointed at a channel someone reads, and a dashboard with request rate, error rate and latency.

That takes a day. It is the difference between finding out from your monitoring and finding out from your client, and clients remember which one it was.