Error monitoring for solo developers: what to set up before you launch
George · 2 min read
The short answer: before launch, set up four things: error tracking for your server and your frontend, an uptime check for your main pages, logs you can search, and a small number of alerts that reach your phone. Then break something on purpose to check that you hear about it. It takes an afternoon and saves your launch day.
On launch day more people use your product in a few hours than in the weeks before. That is exactly when something breaks for the first time: a slow query, a form that fails in one browser, an email provider that hits a limit. The difference between a small hiccup and a bad launch is how quickly you find out.
Error tracking
An error tracking service catches exceptions in your code and groups them, with the stack trace, the page, the browser and what the user did before. Most offer a free tier that is plenty for a new product.
- Track both sides. Server errors and browser errors are different problems. A broken button in one browser never shows up in server logs.
- Upload source maps if your frontend code is bundled, so the traces point to your real code.
- Do not send personal data. Strip passwords, tokens and form contents from error reports.
Uptime checks
An uptime monitor visits your site every few minutes from outside and tells you when it does not answer. Check at least your home page and one page that touches the database, such as the sign-in page or an API health route. A home page served from a cache can look fine while everything behind it is down.
Logs you can search
When a user writes "it did not work", you need to find what happened. Log important events with enough context to follow them, such as the route, the user's id and how long it took, and make sure you can search those logs from your phone or laptop. Never log passwords or full payment details.
Alerts that matter
Too many alerts and you stop reading them. Start with a few:
- The site is down.
- A new kind of error appears.
- Errors suddenly jump well above normal.
- A background job or email sending fails repeatedly.
Send these somewhere you will see them, such as a phone notification or a chat channel you check.
Test it before launch
Throw a test error on purpose, take a page down for a minute, and send a failing request. Confirm that each one reaches you. An alert you have never seen work is not an alert yet.
On launch day
Keep the error tracker open next to your launch post. Fix what affects many people first, reply to anyone who reported a problem, and tell them when it is fixed. Users remember a fast fix more than the bug.
The short version
- Track errors on the server and in the browser.
- Check uptime on a page that uses the database.
- Keep searchable logs without personal data.
- Start with a handful of meaningful alerts.
- Trigger each one before launch to prove it works.