Observe production behavior

Logs tell you what happened to one request. Observability tells you how the whole system behaves over time. It’s only worth the effort if each number you watch leads to a decision. A dashboard full of tiles nobody acts on is decoration.

Four signals are enough to start

For Field Notes I would watch these:

• request volume, so a sudden drop or spike stands out
• error rate, the share of responses that are 5xx
• p95 latency, the response time the slowest 5% of users see
• function duration, how long the server code runs per request

Vercel’s Observability tab shows these per project, and you can break them down by route and by deployment. Add the one external dependency most likely to fail, usually the database, and you have your starting set.

Vercel also offers Web Analytics and Speed Insights for client-side evidence. Check what your plan includes and think about privacy before turning them on.

Averages hide the pain

I want to say a word about p95. An average latency of 180 milliseconds looks great while one user in twenty waits three seconds. The p95 is the value 95% of requests stay under. That’s the number your slow users feel, and the one to watch.

Same with errors. Ten 500s in an hour is nothing on a busy site and a disaster on a small one. Watch the ratio, not the count.

From symptom to cause

A rise in 5xx can come from your code, from the database, or from a third-party API. The deployment id tells you whether it started with a release. The request id lets you find one failing request in the logs. Together they turn “the site is slow” into “the /notes/[slug] route on deployment dpl_7Hk2 started timing out on the database at 14:02”.

Alerts that mean something

Every alert needs three things: an owner, a time window, and a first action. “Error rate above 2% for 5 minutes, page Flavio, first check the runtime logs for the current production deployment” is an alert. “A request failed” is noise.

Alert on sustained impact, not single events. Put the deployment id and the affected route in the notification, so the person woken up starts with context.

And after every release, compare the new deployment with the one before it. If the numbers got worse and you can’t explain why in ten minutes, roll back first and debug later. Users don’t care how interesting the bug is.

Try this on your own project: write a one-page operations note with four signals, their normal range, one alert condition each, and the first log or dependency you’d check when it fires.