# Error tracking, health checks and uptime alerts

> Know about errors and outages before your users tell you: error tracking, a health endpoint and alerts.

Canonical: https://abacklaunch.com/prompts/error-tracking-uptime
Last updated: 2026-10-26

Version 1.0.

On launch day, the worst way to learn the production site is broken is from a comment under the launch post. Make failures visible: errors captured with enough context to fix them, a health endpoint an uptime monitor can watch, and alerts that reach me.

Site: not given. Find the production URL in the project config, or ask me.

## Ground rules

1. Read before you write. Explore the parts of the codebase this job touches and tell me what is already in place.
2. Plan, then stop. Give me a numbered plan: what you will change, in which files, and why. Wait for my approval before editing anything.
3. Fix things at their source (the shared layout, the config, the generator), not with one-off patches page by page.
4. Keep the project's conventions: its framework APIs, file layout, naming and code style. Add no new dependency without asking.
5. Where something is already done well, say so and leave it alone.

## You will not

- Edit `.env` files, secrets or API keys, or print their values.
- Deploy, push, merge or publish anything.
- Delete data, or run migrations or scripts against a production database.
- Add tracking, third-party scripts or links to any site I did not ask for.
- Change copy, design or behaviour that this job does not need.
- Add a paid monitoring service without asking.
- Send personal data or secrets to an error tracker.

## Your stack

- Framework: Work out the framework, router and build output from the project files (package.json, lockfiles, framework config) before planning, and say which you found.
- Host: Work out where the site is hosted from the config files (vercel.json, netlify.toml, wrangler config, Dockerfile, fly.toml) and say which you found.

## Steps

### 1. See what exists

Find any error tracking, logging, health route or monitoring already in place, on the server and in the browser. Note where errors are swallowed (empty catch blocks, failed fetches with no message).

### 2. Capture errors with context

Use the existing error tracking, or propose one (Sentry, Highlight, the host's own) for me to choose; do not add a service without asking. Capture unhandled server errors and browser errors with the route, release version and a request id, and never send passwords, tokens or full card numbers. Replace silent catch blocks on important paths with a log and a user-facing message.

### 3. A health endpoint

Add `/api/health` (or the framework's equivalent) that returns 200 when the app can serve requests and reach its database, and 503 otherwise, quickly and without exposing internals.

### 4. Alerts and a runbook

Write down how to point a free uptime monitor at the homepage and the health endpoint, with alerts to email or chat. Add a short section to the docs: where to read logs and errors, and what to check first when the site is down.

## Done means

- [ ] Server and browser errors are captured with route, release and request id, without secrets.
- [ ] No silent catch block remains on sign-up, checkout or the main pages.
- [ ] A health endpoint answers 200 or 503 quickly.
- [ ] I know how to set up uptime alerts, and the docs say where to look when things break.

## Report back

When you finish, give me:

- what you changed, file by file;
- anything you skipped, and why;
- anything I must do by hand (DNS records, dashboards, accounts, deploys);
- how to check each change on the live site.

## Related

- [Get ready for a launch day traffic spike](https://abacklaunch.com/prompts/launch-day-traffic-readiness)
- [Database backups you have actually restored](https://abacklaunch.com/prompts/database-backups)
- [Rate limits on public endpoints](https://abacklaunch.com/prompts/rate-limits)