Monitoring and alerting for a small SaaS team is one of those subjects where the advice online is nearly all written for engineers at companies with a dedicated platform team, three on call rotations and a budget for whatever observability vendor is fashionable that year. If you are running a bootstrapped product with two or three developers, most of that advice is either irrelevant or actively harmful, because it points you at tooling and process built for a scale you are nowhere near.
I have run monitoring for CampSuite for years now, and I have set it up on more client Dynamics 365 integrations and consulting projects than I can count. The pattern I keep coming back to is deliberately boring. It is not the setup you would build if you were trying to impress another engineer, it is the setup that lets a small team sleep at night and find out about problems before customers do.
Why Small Teams Get Monitoring Wrong
There are two failure modes and I have lived through both of them personally. The first is having no real monitoring at all, so the first sign of trouble is a support ticket or, worse, silence from a customer who has just quietly given up and gone somewhere else. The second is the opposite problem, where someone reads a best practices article, wires up alerts for absolutely everything, and within a fortnight the team has learned to ignore Slack notifications entirely because ninety percent of them mean nothing.
Alert fatigue is the more dangerous of the two, because it looks like you have solved the problem when you have actually made it worse. A team that has learned to ignore alerts will also ignore the one that matters. This is the same trap I wrote about with API rate limiting, where over engineering something that should be simple ends up costing more than the problem it was meant to solve.
What You Actually Need to Watch
Strip it back to the questions that actually matter to your business, not to a generic infrastructure checklist. There are really only three things worth losing sleep over.
Is the Product Up
A simple uptime check hitting your main endpoints every minute or two, from outside your own infrastructure, catches the vast majority of real incidents. This does not need to be clever. A cheap external ping service that alerts you the moment your login page or API stops responding covers more ground than most teams expect, and it is usually the first thing a founder should set up, before anything else on this list.
Are Errors Spiking
Application errors happen constantly in any real product, so the goal is not zero errors, it is spotting when the rate suddenly changes. A single dashboard tracking error rate against a rolling baseline, with an alert that fires on a genuine spike rather than every individual exception, tells you far more than a wall of red log lines ever will. I use this pattern on every project now because it separates the noise from the signal without anyone having to read logs line by line.
Is Something About to Run Out
Disk space, database connections, queue depth, and anything metered that scales with usage. These are the incidents that are entirely predictable and entirely avoidable, and yet I still see them take systems down because nobody set a threshold alert. This ties directly into the work I covered in disaster recovery for small SaaS businesses, because the best disaster recovery plan is the one you never have to use because you saw the problem coming a week early.
Building the Alert, Not Just the Metric
Collecting metrics is the easy part now that most hosting platforms and Azure services give you dashboards for free. The actual skill is deciding what deserves to wake someone up at 2am versus what can wait for the morning standup, and most teams never sit down and make that decision deliberately.
My rule is blunt but it works. If a problem is actively affecting customers right now, it pages someone immediately, on their phone, no exceptions. If it is a warning sign that something will become a problem in the next few days, it goes into a channel that gets checked during working hours. Everything else, every info level log and every metric that is merely interesting, gets a dashboard rather than an alert. Nobody should be woken up by something that can wait until Monday.
Keep the Alert Actionable
Every alert should tell the person receiving it what to do next, not just that something is wrong. An alert that says error rate is elevated is nearly useless at 2am. An alert that says the payment webhook has failed forty times in the last five minutes and here is the link to the dashboard is something a half asleep developer can actually act on. I have thrown away more alerts than I have kept simply because they failed this test.
Tooling That Does Not Need a Platform Team
You do not need a dedicated observability vendor with per seat pricing to do this properly. Application Insights if you are already on Azure, a hosted error tracker, and a cheap external uptime checker will cover the vast majority of small SaaS products, and all three can usually be running within a day. Resist the urge to build a custom logging pipeline before you have outgrown the free tier of the tools that already exist. That instinct to reach for something more sophisticated than the problem needs is exactly what I wrote about when it comes to technical debt in small teams, and monitoring infrastructure is no exception to that rule.
My Honest Take
Monitoring is one of those things that feels optional right up until the moment it saves your product from a genuinely bad day, and by then it is too late to set up properly. The good news is that a useful setup for a small team takes an afternoon, not a sprint, and it does not need anyone with a dedicated ops job title to run it. Watch whether you are up, watch whether errors are spiking, watch what is about to run out, and make every alert actionable enough that whoever receives it knows exactly what to do next.
If you are building out infrastructure for a SaaS product and want someone who has actually run this in production to sanity check your setup, it is exactly the kind of practical decision I help clients work through in development consulting. It is also the sort of unglamorous groundwork I cover in The 28 Day Startup, because the products that stay up are rarely the ones with the most impressive tech stack, they are the ones where someone actually gets told when something breaks.
