To sleep soundly in 2026, an SMB needs to monitor four layers: service availability as seen from the outside, server resources, application logs, and the experience its users actually get. A minimal stack — Uptime Kuma for uptime, Prometheus and Grafana for metrics, simple log centralisation and a handful of well-chosen alerts — covers the essentials for a near-zero licence cost.
Why monitoring is no longer optional
Learning about an outage from a customer call is a double penalty: the incident has already lasted, and it has already dented trust. Monitoring reverses the balance of power: you detect the drift (a disk filling up, response times creeping up, a certificate about to expire) before it becomes an outage, and the outage before it becomes visible. The difference between an SMB that suffers its incidents and one that controls them rarely comes down to budget — more often to the presence of these few guardrails. Monitoring also produces something valuable over time: a history of metrics that makes capacity planning and post-incident analysis far easier.
The 4 layers to monitor
1. External uptime: are your services responding?
Tests performed from outside your infrastructure, exactly as a customer would experience it: HTTP requests on the website and critical applications, checks on SSL certificates and domain expiry. It is the simplest layer to set up, and the one that pays off fastest. A check every minute from two or three locations is enough for most SMBs.
2. Server resources: CPU, memory, disk
A large share of avoidable outages have a trivial cause: full disk, saturated memory, runaway process. Continuously collected metrics, paired with alert thresholds, turn these outages into simple planned-maintenance tickets.
3. Application logs: understanding what happened
Centralising your application logs lets you search in a single place, spot recurring errors and reconstruct the timeline of an incident. Without it, every diagnosis starts with a treasure hunt across several servers.
4. User experience: what your customers actually get
A server can show green while the login or payment journey is broken. Synthetic tests that replay critical journeys, complemented by real response-time measurements, close this last loop.
The minimal open source stack for an SMB
- Uptime Kuma: HTTP, TCP and ping checks, a public status page, alerts to email, Slack or Telegram. Installed in minutes.
- Prometheus + node_exporter + Grafana: server metrics collection and dashboards. The de facto industry standard, with no licence cost.
- Grafana Loki: log centralisation and search without heavy infrastructure, integrating naturally with existing dashboards.
- Alertmanager or Grafana alerts: routing notifications to the right channels by severity.
The cost boils down to a small server dedicated to monitoring — generally 10 to 30 euros per month — plus installation time. One absolute rule: host the monitoring somewhere other than the infrastructure it watches, or it will go down with it. Budget half a day for the initial setup and another half-day to tune the dashboards and thresholds to your context.
What about managed solutions? Datadog, New Relic and friends
Managed platforms offer fast onboarding, zero maintenance and advanced features: APM, automatic correlation, anomaly detection. Their billing model — per host, per gigabyte of ingested logs, per synthetic test — typically amounts to a few tens of euros per host per month. Perfectly reasonable for three servers, the invoice becomes a budget line of its own beyond a few dozen hosts. In between, Grafana Cloud or services like Better Stack offer a middle ground. The right choice depends on three factors: the size of your fleet, the skills available in-house, and how sensitive the data sent to a third party is. Free tiers are convenient to get started, but check the retention and volume limits before relying on them.
The art of useful alerts: avoiding alert fatigue
The classic monitoring trap is not having too few alerts but too many. Three principles are enough to keep alerts credible. First, alert on symptoms — the service is no longer responding — rather than on every possible cause. Second, stick to two levels: urgent, someone must act now, including at night; and warning, handled during business hours. Third, audit monthly: any alert ignored three times in a row must be fixed or deleted, because it is noise that will eventually mask the real outage.
Where to start: the one-day plan
- Morning: install Uptime Kuma, add your 5 to 10 critical URLs, wire up email or Slack notifications, enable certificate monitoring.
- Early afternoon: deploy node_exporter on your servers, set up Prometheus and Grafana, import a standard dashboard.
- Late afternoon: create only three alerts — service unreachable, disk more than 85% full, certificate expiring within 14 days.
- The following weeks: add log centralisation, then user-journey tests, iterating based on real incidents.
One day is enough to go from flying blind to decent visibility. Resist the temptation to build more on day one: a small stack that someone actually watches beats a sophisticated one nobody reads. The next step up — meaningful dashboards, refined alerting, supervision of business journeys — benefits greatly from the experience of people who operate infrastructure daily: it is typically the kind of topic where a few days with a technical partner save months of trial and error.