How do I set up monitoring so I know when my app is down?

Your app went down at 11 PM on a Saturday. You found out Monday morning when a customer sent an angry email. By then it had been offline for 34 hours.

This is not a horror story from 2015. It happens to funded startups in 2024 because most teams treat monitoring as an afterthought, something to sort out after the product is "stable." No product is ever stable. Monitoring is not optional infrastructure. It is the difference between knowing about a problem before your users do and reading about it in a support ticket.

A complete monitoring setup for a small product costs $20–$50 per month and takes an afternoon to configure. The only reason most founders delay it is that nobody explained what it does in plain English.

These two terms get used interchangeably, but they answer different questions.

Uptime monitoring asks one thing: is your app responding right now? A tool pings your app every 60 seconds from a server somewhere in the world. If it does not get a response within a few seconds, it sends you an alert. That is it. Think of it as a smoke detector. It tells you something is wrong. It does not tell you why.

Observability is what you need to answer "why." It covers three areas. Logs are a record of everything your app did, every request it received, every error it encountered, every payment it processed. Metrics are numbers over time: how fast pages load, how much memory the server is using, how many errors per minute are happening. Traces show you the path a single request took through your system, so you can find exactly which step in a multi-step process broke.

For a new product, start with uptime monitoring. Add basic metrics. Get to observability over time as you understand your failure patterns. A 2023 report from PagerDuty found that teams using even basic monitoring cut their mean time to resolve incidents by 63% compared to teams relying on user reports.

The practical difference for your business: uptime monitoring sends you a text at 11 PM on Saturday. Observability tells you within two minutes that the payment service is failing because your database ran out of connections. Without observability you are guessing. With it you are reading.

An alert that goes to a shared inbox nobody watches is the same as no alert. Getting the routing right matters more than which monitoring tool you pick.

The basic model works like this. Your monitoring tool detects a problem and sends a notification. That notification needs to go somewhere a human will actually see it and act on it, at 2 AM if necessary.

For a solo founder or a team of two, the simplest path is a direct text message or phone call. Every major monitoring tool (Better Uptime, UptimeRobot, Betterstack) can call your mobile number when something goes down and escalate to a second number if you do not respond within five minutes. This costs nothing extra on most plans.

For a small team, you want escalation policies. The first alert goes to whoever is on call that week. If they do not acknowledge it within ten minutes, the same alert goes to a backup. Most tools handle this with a simple rotation you configure once. Slack works too, but only reliably for low-urgency alerts. People do not always have Slack notifications turned on at midnight.

A 2024 survey by Atlassian found that 57% of incident response failures traced back to alert fatigue: too many low-priority alerts had trained the team to ignore them. The fix is noise reduction. Every alert should require human action. If an alert fires and the right response is "nothing, this always happens," it should not be an alert. It should either be fixed or silenced.

For routing during the September 2024 period: PagerDuty and Opsgenie are the standard tools for on-call rotation on small teams. Both have free tiers sufficient for a team under five people. The free tier supports one on-call schedule and basic escalation rules, which is all a new product needs.

Most monitoring guides give you a list of 30 things to track and call it comprehensive. Here is what you actually need at launch.

Response time is the metric that most directly correlates with whether users stay or leave. Google's own research found that when a page takes longer than three seconds to load, 53% of mobile users abandon it. Track the time it takes for your app to respond to a typical request. Set an alert if it exceeds two seconds. A spike in response time often predicts a full outage by 10–15 minutes.

Error rate tells you how many requests are failing. Most apps see a baseline error rate below 0.5%. If your error rate climbs above 1%, users are noticing. Above 5% is a crisis. Track this as a percentage, not a raw number, because a hundred errors on a busy day is fine while ten errors on a quiet night might mean something is broken.

Server resource usage covers how much of your server's processing power and memory your app is consuming. If memory usage climbs steadily over 24 hours without resetting, your app has a memory leak. If CPU usage spikes to 90% every time a new user logs in, your login process has a scaling problem. Neither of these shows up in an uptime check until the server crashes.

Database query time is worth adding as soon as you have any meaningful traffic. A database that takes 8 seconds to return a result will make your whole app feel broken even if the servers are running fine. Over 80% of application performance problems originate at the database layer (New Relic, 2024 State of Observability report).

For most small products at launch, a tool like Betterstack or Datadog's free tier covers the first four. The database metrics come later, once you have enough traffic to tell normal patterns from problems.

A monitoring setup sufficient for a product with up to 50,000 monthly active users costs $20–$50 per month. Here is what that buys.

Betterstack (previously Logtail + Uptime) covers uptime monitoring, incident management, and log storage in one product. Their paid plan starts at $24/month and includes one-minute uptime checks from 10 global locations, on-call scheduling, phone and SMS alerts, and 30-day log retention. For a new product this is the only tool you need for the first six months.

Datadog's free tier covers infrastructure monitoring, custom metrics, and one-day log retention at no cost. This is enough for basic server resource tracking while your traffic is low. The paid tier starts at $15 per host per month when you need longer retention or more metrics.

Sentry covers error tracking, a separate concern from uptime. It catches and logs every error a user encounters in your app, including JavaScript errors in their browser that never reach your server. The free tier covers 5,000 errors per month, which is enough for a product still in early growth. Paid plans start at $26/month.

For most small products, Betterstack alone covers the critical cases. Add Sentry when you start having frontend errors you cannot reproduce. Add Datadog's paid tier when you need more than a day of metric history.

Western managed monitoring services charge $500–$2,000 per month to configure and maintain the same stack. The configuration work takes one afternoon. The ongoing maintenance is automated. At Timespade, monitoring setup is part of every product launch, not an add-on, because a product without monitoring is not production-ready regardless of how good the code is.

For context, a 2024 Gartner survey found that unplanned downtime costs small businesses an average of $8,000 per hour. A $24/month tool that cuts your mean time to detect an outage from hours to minutes pays for itself in the first incident.

The full monitoring stack, uptime checks, metric dashboards, error tracking, and on-call routing, is configured during the launch week of every Timespade project. It ships alongside the product, not three months after someone realizes the app went down and nobody noticed.

If you are building a new product and want monitoring built in from day one, Book a free discovery call.