How we look after a product after launch: five habits for measuring in production

A Server-Timing header costs one line and is readable in the browser's Network tab. Ours states how long the read took, how many days came from the cache, how much went to decompressing, mapping, aggregating and collecting. Without it we would have optimized the database when the problem was a date formatter.

Every serverless execution leaves a line in CloudWatch with duration, init time and peak memory. It is the source that says how much headroom is left before a usage spike shows up on someone's screen.

We added live memory, committed memory and the real ceiling of the process to Server-Timing. With that, decisions about caching and concurrency stop being opinions.

A time budget that starts when the heavy work begins ignores cold start, credentials and serialization. The clock must start when the request enters, and a partial response must say it is one.

A 1024 MB Lambda has a little over half a CPU. A loop that takes one second on a laptop takes ten there. We measured locally against production data to understand memory, but CPU decisions were made with numbers from the real function.

With those five habits, the operations console of one of our clients went on to deliver a full month of metrics in six seconds. None of them needs new tools: only looking at what is already there, every week.