- Start with what users feel: is the app up, are requests failing, and is it slow?
- Google's SRE book names four golden signals to watch on a user-facing system: latency, traffic, errors and saturation.
- Also watch the quiet parts that fail silently: scheduled jobs, queues, backups, certificates and domain renewals.
- Alert a person only for problems that need action now; send everything else to a dashboard or a daily summary.
- Every alert should name the problem, link to the evidence and say who owns it.
What should you monitor on a production web app?
Monitor what users experience first (uptime, error rates and response times), then the resources that cause problems (traffic and how full your servers and databases are), and the quiet parts that fail silently (scheduled jobs, queues, backups, certificates and domains), with alerts only for problems that need someone to act now. You do not need a large monitoring setup to start. A small, well-chosen set catches most incidents before customers report them.
This is the baseline our cloud and DevOps team sets up for client applications.
What are the four golden signals?
Google's Site Reliability Engineering book, in its chapter on monitoring distributed systems, says that if you can only measure four metrics of a user-facing system, they should be latency, traffic, errors and saturation:
| Signal | What it tells you | Example measure |
|---|---|---|
| Latency | How long requests take | Response time of key pages and API calls |
| Traffic | How much demand the system has | Requests per minute, active users |
| Errors | How many requests fail | Rate of server errors and failed checkouts |
| Saturation | How full the system is | CPU, memory, disk, database connections |
The same chapter notes that slow errors and fast errors should be tracked separately: a quick error page is not a fast success.
How do you know the app is up?
Use an external uptime monitor that loads your key pages from several locations and checks the response, not just that the server answers. Check a page that touches the database, such as a login page or a product page, so a database failure shows up. For important flows, a synthetic check that signs in or adds an item to the cart catches problems a simple ping misses.
How should you track errors?
An error tracking tool collects exceptions from your server and the browser, groups duplicates, and shows the stack trace, the release that caused it and how many users are affected. Alert on new error types and on sudden increases, not on every single error. Link errors to releases, so the team can quickly see whether the last deployment caused a problem.
How do you watch performance?
Track server response times for your most important endpoints, and watch real-user performance in the browser too. For public websites, the Core Web Vitals report in Google Search Console shows how real visitors experience your pages; our Core Web Vitals guide explains the metrics. Slow database queries are a common cause of slow pages, so enable slow query logging on the database.
Which failures are silent?
- Scheduled jobs: invoices, reminders and reports that stop running. Use heartbeat checks that alert when a job has not reported in on time.
- Background queues: watch queue length and the age of the oldest job.
- Backups: alert when a backup is missing or unusually small, and test restores regularly.
- SSL certificates: alert well before expiry, even with automatic renewal.
- Domain renewals: an expired domain takes everything down.
- Disk space: logs and uploads fill disks slowly, then suddenly stop the app.
- Email sending: bounce rates and failures in transactional email.
How do you monitor third-party services?
Most applications depend on outside services: payment providers, email delivery, maps, SMS and AI APIs. When one fails, your app looks broken even though your servers are fine. Track error rates and response times for each outbound call, subscribe to each provider's status page, and design fallbacks where you can, such as queuing emails for retry instead of failing the user's action.
What should your logs include?
Good logs make incidents short. Use structured logs with a timestamp, severity, request ID, user or account ID (not personal details), the action and the outcome. Send them to one central place with a retention period that matches your needs and your privacy policy. Then you can follow a single failing request across the web server, queue and database instead of searching several machines.
Which problems should wake someone up?
The SRE chapter separates symptoms (what is broken from the user's point of view) from causes (why it is broken), and advises alerting on symptoms that need a human to act. In practice:
- Page someone now: the app is down, checkout or sign-in is failing, error rates have jumped, the disk is about to fill.
- Send to the team channel: performance is degrading, a queue is building up, a certificate expires in two weeks.
- Daily summary or dashboard: traffic trends, resource usage, minor errors.
What makes a good alert?
- It describes the user impact in plain words.
- It links to the dashboard, logs or error that triggered it.
- It has an owner and a short runbook: what to check first.
- It fires only after the problem lasts long enough to matter.
- It resolves itself when the problem clears, so nobody chases a fixed issue.
How should a small team start?
If you have just inherited the application from another developer, run a first-week takeover audit alongside this plan.
- Week one: external uptime checks on key pages, error tracking on server and browser, and alerts to one shared channel.
- Week two: heartbeat checks for scheduled jobs and backups, certificate and domain expiry alerts, disk space alerts.
- Week three: response time tracking for key endpoints and a simple dashboard with the four golden signals.
- Monthly: review every alert that fired, delete the noisy ones and fix the causes of repeated incidents.
If you would rather not run this yourself, our maintenance and security plans include monitoring and response, and our custom software team builds health checks into the applications we develop. For automation servers you host yourself, our guide to self-hosting n8n safely covers the same principles.
Frequently asked questions
Is uptime monitoring enough for a small web app?
It is a good start, but not enough on its own. Uptime checks only tell you the homepage responds. Errors in checkout, a stopped background queue or a failed backup can all happen while the site still looks up. Add error tracking and checks for scheduled jobs and backups as soon as the app handles real customers or money.
How often should uptime checks run?
Many monitoring services check every minute or every few minutes from several locations. Checking from more than one location avoids false alarms caused by a single network problem. Choose a frequency that matches how quickly you need to know, and alert only after a check fails more than once in a row.
Where should alerts go?
To the people who can fix the problem, through a channel they actually watch: a paging app for urgent problems, a team chat channel for warnings, and email or a dashboard for daily summaries. Avoid sending every alert to one busy inbox, where important messages get lost among routine ones.
Do we need a dedicated monitoring tool or is the hosting dashboard enough?
Hosting dashboards show server health but rarely show application errors, slow pages or failed jobs. A small set of tools usually covers the gap: an uptime checker, an error tracker and logs with alerts. Larger systems add application performance monitoring and centralised logging.
How do we avoid alert fatigue?
Review every alert that fired in the last month. Remove or tune any that nobody acted on, raise thresholds that trigger on harmless blips, and combine duplicates. An alert that is ignored is worse than no alert, because it trains people to ignore the next one, which may be real.
Last updated