Monitoring and Observability for Small Teams: What to Track Without Drowning in Data

I once worked at a startup that had more monitoring dashboards than customers. We had Datadog, Grafana, Prometheus, PagerDuty, custom dashboards for every microservice, and alert rules so numerous that everyone had muted their PagerDuty channel. When the site went down for 45 minutes, nobody noticed because the real alert was buried among 200 daily false positives.

This is the observability trap: too much data, not enough signal. For small teams (under 20 engineers), you need a minimal setup that catches real problems without creating noise. Here is what actually works.

The Three Pillars (But Only Two Matter at First)

Observability has three pillars: metrics (numbers over time), logs (event records), and traces (request journeys through your system). Enterprise teams need all three. Small teams need two: metrics and error tracking.

Why not traces initially? Distributed tracing is essential for debugging complex microservice architectures. If you have 3-5 services (typical for a small team), you can debug most issues by correlating timestamps in logs. Traces become essential at 10+ services. Add them when you get there.

Why not complex logging initially? Structured logging with log aggregation (Loki, CloudWatch Logs, Datadog Logs) is useful but often overkill. For small teams, application error tracking (Sentry) catches the important stuff, and you can SSH into a server or check container logs for the rest.

The Minimal Stack

Here is what I recommend for teams of 2-10 engineers:

Sentry for error tracking. Captures every unhandled exception with full stack trace, request context, user information, and breadcrumbs. Groups related errors. Alerts on new issues. This alone catches 80% of the problems you care about.

Uptime monitoring for availability. A simple external check that pings your critical endpoints every 60 seconds and alerts when they fail. BetterUptime, Uptime Robot, or even a free tier checker. Know when your site is down before your users tell you.

Vercel Analytics (or equivalent) for Core Web Vitals. Real user performance monitoring. If your p75 LCP degrades from 1.5s to 4s, you need to know immediately — not after a user complains.

That is it. Three tools. One for errors, one for availability, one for performance. Total cost: $0-50/month depending on tiers.

What Metrics Actually Matter

If you do set up a metrics dashboard (Grafana, Vercel's built-in, or your hosting platform's metrics), track these and only these:

Request rate (requests per minute). Establishes your baseline. A sudden drop means something is broken or traffic is being blocked. A sudden spike means you are being shared on social media or attacked.

Error rate (4xx and 5xx per minute). Should be near zero for 5xx. A spike in 500 errors is the highest-priority alert. 4xx rates help identify broken links or misconfigured clients.

Response time (p50 and p95). The p50 shows typical performance. The p95 shows worst-case performance for 1 in 20 users. Alert on p95 degradation — it catches problems before they affect the majority.

Database query time (p95). Slow queries are the most common cause of slow pages. A single unindexed query in a hot code path can degrade the entire application.

CPU and memory usage. Not for constant monitoring — for understanding capacity. If you are consistently above 80% CPU, you need to scale up before a traffic spike causes an outage.

Alerting Without Alert Fatigue

The number one rule of alerting: every alert must be actionable. If an alert fires and the on-call engineer cannot take a meaningful action in response, the alert should not exist.

Alert on symptoms, not causes. Alert on "error rate above 1%" not "CPU above 70%." The error rate alert tells you users are affected. The CPU alert tells you... maybe nothing useful. High CPU might be fine during a build.

Use severity levels: critical (pages someone immediately — site is down), warning (notifies the team channel — investigate soon), info (recorded in dashboard — review during working hours). Most teams only need critical and warning.

Start with zero alerts and add them reactively. When an incident happens that should have been caught earlier, add an alert for it. This ensures every alert corresponds to a real scenario, not a hypothetical one.

Our alerts at AIDToolStack:

Critical: 5xx error rate above 5% for 2 minutes (site is broken)

Critical: uptime check fails for 3 consecutive checks (site is unreachable)

Warning: p95 response time above 3 seconds for 5 minutes (performance degradation)

Warning: new Sentry issue with 10+ occurrences (repeated error affecting users)

Four alerts. That is the entire alerting configuration. Each one has fired at least once for a legitimate reason.

Error Tracking in Depth

Sentry is our most valuable monitoring tool by far. Here is how we configured it for maximum value:

Source maps in production. Without source maps, Sentry shows minified stack traces that are useless for debugging. Upload source maps during your build step so Sentry can show the original TypeScript line numbers.

User context. Attach the user ID and email to Sentry events. When a user reports a problem, you can search Sentry for their errors immediately instead of asking them to reproduce it.

Performance monitoring (Sentry Transactions). Sentry can track the duration of API routes, database queries, and external calls. This overlaps with dedicated APM tools but is often sufficient for small teams.

Release tracking. Tag each deployment with a version. Sentry shows which release introduced a new error, making it trivial to identify the responsible commit.

Ignore noise. Configure Sentry to ignore expected errors: cancelled network requests (user navigated away), 401 responses from auth-required endpoints, browser extension interference. This keeps the issue list clean and the alerts meaningful.

When to Level Up

Upgrade your observability stack when:

You cannot reproduce a bug from Sentry alone. If you need request-level visibility across services, add distributed tracing (OpenTelemetry + Jaeger or your APM's tracing feature).

You are guessing about infrastructure capacity. Add infrastructure metrics (Prometheus + Grafana or your cloud provider's metrics) when you need to plan scaling decisions.

Your team grows beyond 10 engineers. More services, more complexity, more people means you need structured logging and centralized log aggregation for coordination.

You have an SLA to meet. If customers pay for 99.9% uptime, you need proper SLO tracking, error budgets, and historical availability reporting. This requires more sophisticated tooling.

The Anti-Patterns

Do not monitor everything because you can. Every dashboard you create is a dashboard you need to maintain and check. Every metric you track is cognitive load. Be ruthless about what deserves attention.

Do not buy enterprise tools for startup problems. Datadog is incredible — and costs $15-30 per host per month for infrastructure monitoring alone. At 10 servers, that is $150-300/month for metrics you might check once a week. Start with free tiers and upgrade when free is genuinely insufficient.

Do not build custom monitoring. I have seen teams spend weeks building custom dashboards that Vercel Analytics or Sentry provide out of the box. Your time is better spent building product features. Use off-the-shelf tools unless you have a genuinely unique requirement.

Do not alert on metrics you do not understand. An alert for "disk I/O above 80%" is useless if you do not know whether 80% is normal for your workload. Understand your baselines before setting thresholds.

Our Journey

AIDToolStack started with just Sentry and an uptime checker. That covered us for six months. When we added the API marketplace and started getting sustained traffic, we added Vercel Analytics for performance monitoring. We still do not have dedicated infrastructure metrics or distributed tracing because we do not need them at our scale.

The best monitoring setup is the simplest one that catches real problems before users report them. Start minimal, add tools when you hit a concrete debugging limitation, and ruthlessly prune alerts that do not lead to action.