The worst way to learn your site is down is from a customer. Monitoring tells you first, and good alerting tells the right person without waking the whole team for noise. A small team can get most of the value with a handful of tools and a few clear rules.
What to watch
- Availability: is the site reachable and responding correctly?
- Errors: are users hitting exceptions or failed requests?
- Latency: are pages and APIs responding fast enough?
- Resources: CPU, memory, disk and database connections.
- Business signals: sign-ups, orders and form submissions. A sudden drop often points to a bug before any technical alarm fires.
Layer 1: uptime checks
Use an external service such as UptimeRobot, Better Stack or Pingdom to request your home page, login and a key API route every minute from outside your network. Check for the expected status code and a word in the response, not only that the server answered. Add a check for SSL certificate expiry and for domain renewal dates, because expired certificates and domains take sites down every week.
Layer 2: error tracking
Add Sentry, Rollbar or a similar tool to the front end and the back end. It groups the same error, shows the stack trace, the release and the user's browser, and tells you how many people were affected. Upload source maps so traces point to readable code, and tag each deploy so you can see which release introduced a problem.
Layer 3: logs you can search
- Write structured JSON logs with a timestamp, level, request ID and route.
- Never log passwords, tokens or full message contents.
- Ship logs to a searchable service such as Better Stack, Grafana Loki or your cloud's log tool.
- Keep logs long enough to investigate, often 14 to 30 days, and cheap enough to afford.
Layer 4: metrics and traces
As the app grows, track request rate, error rate, latency percentiles and saturation. Use the four golden signals as a base: latency, traffic, errors and saturation. Watch the 95th percentile rather than the average, because averages hide the slow requests that frustrate users. Add tracing, for example with OpenTelemetry, when you have several services and need to see where time goes.
Alert on symptoms, not every blip
Too many alerts teach people to ignore them. Page someone only when users are affected and action is needed now.
- Page immediately: site down, checkout failing, error rate above a set threshold for five minutes.
- Notify during the day: disk 80 percent full, certificate expiring in 14 days, slow queries rising.
- Record only: brief spikes that recover on their own.
Route alerts to where people look
Send urgent alerts to a phone through a push app, SMS or a call, and routine ones to a team chat channel. Include a link to the dashboard and a one-line hint about the first thing to check. Agree on who is on call each week, even if the team has only three people.
Write a short runbook
- How to check whether the site, database and third-party services are up.
- How to roll back the last release.
- Who to contact at the host, domain registrar and payment provider.
- Where the backups are and how to restore them.
Learn from each incident
After any outage, write down what happened, how you found out, how long it took to fix and one change that prevents a repeat. Keep it blameless. Over a year, these notes improve reliability more than any tool. For the deployment side, see Automating Deployments with CI/CD.
An example alert plan for a small team
A three-person team runs a web app, an API and a WhatsApp webhook. They set an uptime check on each, an error alert when more than 20 errors occur in five minutes, a daily message when disk use passes 80 percent, and a weekly summary of slow queries. Urgent alerts go to a phone, everything else to a team channel. Total setup time was one afternoon, and the first outage was caught by the alert, not by a customer.
Monitor the jobs nobody sees
- Scheduled jobs such as backups, reports and reminders. Alert when one does not run, not only when it fails.
- Queues. Watch their length and the age of the oldest message.
- Third-party services, such as email and payment providers. Track their error rates from your side.
What we watch in our own products
For the Lena Dena platform, that means checking invoicing, login and report pages, plus scheduled jobs such as due-date reminders sent to customers on WhatsApp. Quiet failure is the risk: if a reminder job stops, nobody notices until payments run late. WhatsApp bots need their own checks, such as whether webhooks arrive, whether replies succeed and whether the message template quota is healthy, as in our WhatsApp automation. Alerts for those flows protect real money and real customer relationships.
We set up monitoring, deployment and support for client applications. See our services or contact us for ongoing care of your product.