Adding Observability to an App You Inherited

You now own an app you did not write. Maybe a contractor delivered it, maybe a cofounder generated it in Lovable over a long weekend, maybe it came with an acquisition. Either way, when a customer emails "it's not working," your investigative toolkit is asking them for a screenshot.

Observability is the fastest way to buy competence in a codebase you do not understand yet. Reading unfamiliar code teaches you what it was meant to do; instrumentation teaches you what it actually does, under real traffic, with real data. On a rescue engagement it is the first thing we install, before any refactoring, because every later decision gets better when you can see. Here is what to wire up, in what order, and where to stop.

Four signals, and only four

Ignore the vendor taxonomy. There are four questions you need answered, and each maps to one thing you install.

Everything else — RUM, profiling, session replay, custom metric dashboards — is a later purchase. Teams get this backwards constantly: they buy the platform with the impressive dashboard, spend two weeks configuring it, and still cannot answer "which user hit this error."

Day one: error tracking

If you install exactly one thing, install this. Sentry, Rollbar, Bugsnag, or equivalent — the choice barely matters and free tiers cover a small app. Three details separate error tracking that helps from noise you eventually mute:

Tag every event with the release. Wire your deploy to send a release identifier and source maps. Without it you get a stack trace pointing at minified line 1, column 40,000. With it you get the actual file and line, plus the ability to see that a spike began at 14:02 with the deploy you shipped at 14:01.

Attach user context. User id, plan, tenant. The moment an error is attached to a customer, support and engineering stop being separate investigations.

Capture on both sides. Inherited apps almost always instrument the server and forget the browser, leaving the entire category of client-side failure invisible — including the blank white screen in production that server logs will never show you.

Expect the first 48 hours to be ugly: a typical inherited app surfaces dozens of errors that have been failing silently for months. That backlog is not a crisis, it is a map. Sort by user count, fix the top five, mute the browser-extension noise, move on.

Day two: logs you can actually search

Most inherited apps log by printing strings. That is fine for tailing output during development and useless once you need to answer a question about last Tuesday.

Two changes convert prints into an investigative tool. First, log structured objects instead of sentences, so every line carries fields — level, message, request id, user id, route — that you can filter on. Second, generate a request id at the edge of every request and thread it through everything that request touches, including background work it triggers. That single id turns a pile of interleaved lines from 200 concurrent users into one readable story.

Then set retention deliberately. Thirty days covers nearly every real investigation; longer retention on a chatty app is where observability bills quietly become a line item you notice. There is more depth on format, levels, and what never to log in logging practices for a startup.

One warning specific to AI-generated code: generated logging statements routinely print entire request bodies and response objects. That is how tokens, password reset links, and customer PII end up in a third-party log platform with a searchable index. Grep for logging calls that pass whole objects before you turn on shipping to a vendor.

Day three: traces, or at least timings

Full distributed tracing on a three-service app is usually overkill. What you need is the ability to break one slow request into its parts: how long in the database, how long waiting on an external API, how long rendering.

Most application performance tools give you this with an auto-instrumenting SDK and a few lines of setup. The payoff is immediate and specific — nearly every "the app feels slow" complaint resolves into one of three findings: a query with no index, an N+1 pattern issuing 300 queries where one would do, or a synchronous call to an external service on the request path. The third one is a design problem, and the fix is moving that work into a background job. The first two are covered in more detail in why your website is slow.

Day four: uptime checks that reflect reality

A ping to the homepage tells you the CDN is up. It does not tell you that login is broken, which is what your customers mean by "down."

Write synthetic checks against the paths that matter: log in, load the main dashboard, hit one authenticated API endpoint. Run them every minute from at least two regions. Alert on two consecutive failures, not one, unless you enjoy being paged by transient network blips.

And check the boring things too. A cron that has silently stopped running is one of the most common failures in inherited apps, because nothing errors — the work simply does not happen. A heartbeat check on every scheduled job catches it in minutes instead of when a customer notices their weekly report never arrived.

What to skip, and what this costs

Skip session replay until you have a UX question you cannot answer another way. Skip building custom dashboards before you have alerts. Skip any tool priced on data volume until you know your volume, because a chatty AI-generated app can produce a startling amount of it.

Budget-wise, a small SaaS should be able to run error tracking, logs, basic traces, and uptime for somewhere in the tens of dollars a month, and certainly under a few hundred. If you are looking at four figures on an app with a few thousand users, someone has enabled full-fidelity sampling on everything. Turn the sample rate down; you do not need every trace, you need a representative one.

The last piece is turning signals into a decision. Alerts should be few, actionable, and routed to a human who is expected to respond — the ground covered in monitoring and alerts for a small SaaS. Instrumentation without a response plan is a very expensive way to have a record of your outage after the fact, which is why an incident plan for a solo founder belongs in the same week of work.

If you are at the very start of taking over unfamiliar code, observability pairs naturally with the broader orientation checklist in inheriting an abandoned codebase.

Frequently asked questions

What should I install first on an app I did not write? Error tracking with release tagging, source maps, and user context, on both the server and the browser. It takes under an hour, requires no understanding of the codebase, and immediately shows you what is failing and for whom. Everything else is easier once you have that list.

How much observability does a small SaaS actually need? Errors, structured logs with a request id, basic request timings, and synthetic uptime checks on the login and main dashboard paths. That covers the overwhelming majority of real incidents. Session replay, profiling, and custom metric platforms are worth adding when you have a specific question they answer, not before.

Will adding instrumentation slow my app down? Not measurably, if configured sanely. Error tracking is negligible. Tracing adds a small amount of overhead, which you control with sampling — 10% of requests is plenty for finding patterns. The real risk is not performance but cost and privacy: unbounded log volume and generated log statements that dump full request bodies into a vendor's index.

---

If you have inherited an app and your only debugging tool is a customer's screenshot, instrumentation buys you more in a week than reading the code does in a month. SprintX instruments inherited and AI-generated applications, then uses what the data shows to prioritize the actual fixes — tell us what you took over.