After You Ship

The worst way to learn about an outage is a message from someone who hit it an hour ago. Two things fix most of that, and both are free at small scale.

1. 1

   Error tracking

   Sentry or your host's built-in equivalent. It reports what broke, on what page, with the stack trace and browser.

   Add error tracking first: it tells you what broke, where, and on which browser.

2. 2

   Uptime checks

   A service that loads your site every few minutes and emails you when it stops responding.

You are not building an observability practice. You are answering two questions: is it up, and is it throwing errors.

Real reports are vague. “It doesn’t work” is the median. Your job is to convert that into something reproducible before you prompt anything.

The fourth catches a surprising share of issues outright — a layout that only breaks on Safari, or a feature that assumed a mouse.

A live bug and a bug caught in review are not the same problem. One of them is actively costing someone something right now, and the instinct to fully understand it before you touch anything is exactly backwards under that kind of pressure.

If the last deploy is the obvious suspect — a change went out an hour ago and the errors started ten minutes later — the fastest fix is usually not a fix. It is putting the previous, known-good version back in front of people, then debugging calmly with the fire already out.

1. 1

   Is the last deploy the suspect?

   Check error timestamps against your deploy log. A tight correlation is your answer before you have read a single line of the diff.

2. 2

   Can you undo it in under a minute?

   Most hosts let you redeploy the previous build directly, and a git revert undoes the commit without rewriting history the way a reset would.

3. 3

   Roll back, then debug

   Once the previous version is live, you are debugging a problem, not fighting an outage. Those are different tasks, and the second one is much easier to think clearly about.

$ git log --oneline -5$ git revert <bad-commit-sha>$ git push

Once you can reproduce it, the loop is the one you already know — with one addition that stops the same bug returning:

Users on Safari cannot submit the contact form. I reproduced it:the date field stays empty and the submit button does nothing.Works in Chrome. Relevant file: src/components/ContactForm.tsx First write a test that reproduces this, then explain the cause,then fix it.

Test first, cause second, fix third. The test is what makes this a permanent fix rather than a temporary one.

Skip the test and you have closed today’s report. The same defect can resurface through a different input next month, and nothing will flag it until another user finds it — now annoyed twice, by the same bug you already fixed once.

Analytics answer questions your intuition cannot. Which pages do people land on? Where do they leave? Which feature you spent a weekend on has never been used?

A privacy-respecting analytics tool — Plausible, Fathom, or your host’s built-in option — is a few lines to add and does not require a cookie banner. Start with page views. Do not build a dashboard nobody reads.

A shipped project needs maintenance that is easy to skip because nothing is visibly broken:

1. 1
   Update dependencies monthly

   npm outdated shows what has moved; run your check command after updating.

2. 2
   Act on security advisories

   npm audit, and GitHub will open PRs for you if you enable Dependabot.

3. 3
   Keep your rules file current

   It rots, and a stale one confidently misleads the AI.

4. 4
   Delete what is unused

   Every feature nobody uses is still code you have to keep working.

Most projects get few users, and that is a normal outcome rather than a failure. The value of shipping is not traffic — it is that reality gives you feedback that imagination cannot.

One real user hitting one real bug teaches you more about building software than another week of adding features in private. Ship the small thing, watch what happens, and let that decide what you build next.