For too long, structured logging and monitoring were things we added to a project reactively, usually right after an incident made the gap obvious. This year we made a short observability baseline part of every project's initial setup, rather than something bolted on later under pressure.
What the baseline actually includes
- Structured JSON logs from day one on every service, rather than free-text `console.log` output that is painful to search later
- Error tracking (we use Sentry across most projects) wired in during initial setup, not after the first unhandled exception in production
- Basic uptime and latency alerting live before launch, not after the first client complaint about a slow page
- A minimal health-check endpoint on every service, used both by our own monitoring and by whatever hosting platform's own load balancer needs it to determine instance health
Why we finally made this a checklist item rather than a best intention
None of this is new or exotic advice — every team we know would agree, in the abstract, that logging and monitoring matter. What actually changed this year was moving it from a best intention, easily deprioritized under deadline pressure, into a literal checklist item that a project cannot be marked ready for its first client demo without completing, the same way we already treat things like SSL configuration or basic accessibility checks as non-negotiable rather than optional nice-to-haves.
A specific incident that made the gap impossible to ignore any longer
The concrete trigger for finally formalizing this was an incident on a client project last year where a slow memory leak went unnoticed for nearly two weeks, visible only in retrospect as a slow, steady climb in a metric nobody was actually watching in real time, because the project's monitoring setup had been added reactively after an earlier, unrelated incident and had never been extended to cover memory usage specifically. By the time a developer noticed the service's periodic restarts by chance, the leak had already caused several brief unplanned outages that a proper baseline, watching for gradually degrading trends rather than just hard failures, would have caught and flagged as a warning trend weeks earlier.
How this changed our project kickoff process
Every new project's kickoff checklist now includes standing up this baseline before any client-facing feature work begins, treated as part of the project's actual infrastructure setup rather than a separate, later phase. This did add a small amount of time to a project's very first sprint, typically less than a day of engineering effort given how much of the setup is now templated from a shared internal starter, but it has consistently paid that time back the first time an issue surfaces that the baseline catches early rather than a client noticing and reporting it first.
What "basic alerting" actually means in practice
We deliberately scoped the alerting portion of this baseline narrowly at first — uptime, error rate, and latency past a fixed threshold — rather than trying to alert on everything conceivably useful from day one, since an alerting setup that pages someone for too many low-value signals trains the team to start ignoring alerts altogether, which defeats the entire purpose. Additional, more application-specific alerts get added deliberately as a project matures and the team develops a real sense of which metrics actually predict a genuine problem for that specific application, rather than guessing broadly at project kickoff before there is any real production traffic pattern to calibrate against.
Rolling this baseline out across our existing older projects
Beyond new projects, we have also been retrofitting this same baseline onto a handful of older client projects that predate the new checklist, prioritized by which ones handle the most business-critical traffic for their respective clients. This retrofit work is genuinely more involved than building it in from the start, since it means auditing what logging and monitoring, if any, already exists on a given project and filling in gaps without disrupting a live, already-running service, but we consider it worth the investment given how much earlier problems like the memory leak incident above would have been caught with this baseline already in place.
The actual cost of running this baseline, even on a small project
A fair question from a client watching their own hosting bill closely: does a full observability baseline meaningfully add to a small project's running costs? In practice the added cost has been minor for every project we have set this up on so far — most of the tools involved, including the tier of Sentry we use for smaller projects, have a free or low-cost tier that comfortably covers a typical client project's actual traffic volume, and the health-check endpoint itself costs nothing beyond a few lines of code. The real cost of this baseline was never the tooling; it was the engineering discipline of setting it up before it feels urgently necessary, which is exactly the discipline problem the new checklist step is meant to solve.
A shared starter template that makes this nearly free to add now
To keep the "small amount of time added to a project's first sprint" genuinely small rather than a recurring source of scope creep, we built a shared internal starter template with the structured logging, error tracking, and health-check endpoint already wired in and ready to configure with a new project's specific credentials. A new project now starts from this template rather than building the baseline from scratch each time, which has brought the actual setup time down from what was originally closer to a full day of work to just a couple of hours of project-specific configuration, mostly just plugging in the new project's own error-tracking project key and alerting destination.
Making sure alerts actually reach a human, not just a dashboard
An alert configured to fire but routed nowhere anyone actually monitors is barely better than no alerting at all, so part of the baseline checklist now explicitly requires confirming, with the client if they will be involved in ongoing operations, exactly who receives an alert and through what channel — a shared Slack channel, an on-call phone rotation, or simply our own team's own on-call rotation for projects where we retain full operational responsibility after launch. This sounds like an obvious thing to confirm, but we found, while formalizing this checklist, that at least two existing projects had alerting configured and technically firing correctly into an email inbox nobody was actually checking regularly, which is exactly the kind of silent gap this whole baseline effort is meant to close.
Results
None of this is new or exotic advice, but making it a checklist item at project kickoff, rather than a best intention that gets deprioritized under deadline pressure, has meaningfully changed how quickly we catch issues across our client projects this year. We have already caught at least two developing problems — a slowly growing error rate on one project and a latency regression on another — early enough to fix them calmly during business hours, rather than the middle-of-the-night pages that reactive-only monitoring tends to produce once a problem has already become severe enough to be unmissable.
Extending the baseline to a client's own internal tools, not just client-facing services
A couple of clients also asked us to apply this same baseline to their own internal tools — admin dashboards and internal reporting scripts that we do not typically instrument as carefully as a customer-facing application, on the reasoning that an internal tool failing quietly is lower stakes than a customer-facing outage. We pushed back gently on that reasoning in a couple of cases where the internal tool in question turned out to be load-bearing for the client's own daily operations — an internal order-processing dashboard, for instance, where a silent failure would have meant orders quietly not getting processed rather than a visible customer-facing error — and extended the same baseline there once the actual operational stakes became clear. This experience updated our own default assumption: we now ask explicitly, for every internal tool a client asks us to build, whether its failure would actually be low-stakes or whether it is secretly business-critical, rather than assuming "internal" automatically means "lower priority for observability. We expect to keep refining this baseline as we learn more from each project it gets applied to, treating it as a living checklist rather than a document we finalize once and never revisit again.