Logging and Observability for Small Applications: What to Track Without Overengineering
Enterprise observability: Datadog, Grafana, Prometheus, distributed tracing, custom metrics dashboards, log aggregation pipelines. Cost: $500-5000/month. Appropriate for: applications with millions of users and dozens of services.
Your application: one service, maybe a background worker, a few thousand users. You need to know: is it working? If not: what broke? The enterprise stack is wildly over-engineered for this scale.
Here is the minimal observability setup that catches 95% of issues at near-zero cost.
The Three Signals You Need
For a small application, you need three things:
Everything else (distributed tracing, custom metrics, log aggregation) is useful but not essential at small scale.
Error Tracking: Sentry (Free Tier)
Sentry captures unhandled errors with full context: stack trace, request details, user information, browser/device data, and breadcrumbs (what happened before the error).
Setup: install the Sentry SDK, configure with your project DSN, and errors automatically report. For Next.js: their official integration captures both client and server errors.
The free tier: 5,000 errors/month. For a small application: this is sufficient unless something is catastrophically broken (in which case: you want to know about it immediately).
What Sentry gives you: instant notification when new errors occur (email or Slack), error grouping (same error from different users grouped into one issue), release tracking (which deploy introduced this error?), and context (what was the user doing? what were the request parameters?).
This single tool replaces: manual log checking, user bug reports as your error discovery mechanism, and "works on my machine" debugging without production context.
Uptime Monitoring: BetterUptime or UptimeRobot (Free Tier)
A simple HTTP check every 1-5 minutes: is the site responding? If not: alert via email/SMS/Slack.
Setup: provide your URL, configure check frequency and alert channels. Done in 2 minutes.
What this catches: server crashes, deployment failures, DNS issues, certificate expiration, and database connection failures.
Free tiers: UptimeRobot offers 50 monitors at 5-minute intervals. BetterUptime offers 10 monitors. Sufficient for a small application (main URL + API health endpoint).
Application Logging: Structured JSON Logs
For request logging: output structured JSON logs. Each log entry contains: timestamp, request method and URL, response status code, response time, user ID (if authenticated), and any additional context (error message for failed requests).
In Next.js: middleware can log every request. Or use a logging library (pino for Node.js — fast, JSON output, minimal overhead).
Where logs go: depends on hosting. Vercel: logs are available in the dashboard (retained for limited time on free tier). Railway/Render: logs in their dashboard with longer retention. Self-hosted: write to stdout and use a log viewer.
Important: do NOT log sensitive data. No passwords, no tokens, no full credit card numbers. Log user IDs (for debugging) but not personal information (for privacy/compliance).
Health Check Endpoint
Create a /api/health endpoint that checks: application is running (obviously — it responds), database is connected (attempt a simple query), and external services are reachable (if critical).
Return JSON with status: { status: "healthy", database: "connected", uptime: "72 hours" }. Or return 503 if unhealthy: { status: "unhealthy", database: "disconnected", error: "Connection timeout" }.
Point your uptime monitor at this endpoint. It catches: database connection issues (even if the app process is running), out-of-memory conditions (app cannot respond), and configuration problems (missing environment variables that crash on first use).
Performance Monitoring (Lightweight)
Do not set up Prometheus + Grafana for a small app. Instead:
Vercel Analytics (free tier): Core Web Vitals for your pages. LCP, FID, CLS. Identify slow pages without custom instrumentation.
Simple response time logging: log response times in your request logger. When investigating slowness: grep logs for requests over 1 second. No fancy dashboard needed — terminal grep is sufficient at small scale.
Database query logging: Prisma's logging (event-based) can output slow queries. Enable in development, disable in production (unless investigating a specific issue).
Alert Configuration
The key to useful alerts: minimal, actionable, and not noisy.
Alert on: site down (uptime monitor), new error type in Sentry (first occurrence of an error you have never seen), and error spike (10x normal error rate in a short period).
Do NOT alert on: every single error (alert fatigue — you stop checking), expected errors (404s from bots, rate-limited requests), and low-severity issues (can wait until morning).
Configure alerts to reach you: Sentry → Slack channel (for awareness) + email for critical issues. Uptime → SMS for site-down (this is urgent and should wake you up if necessary).
Debugging Workflow
When an issue occurs:
Total time from alert to understanding: usually 5-10 minutes. Without these tools: you learn from user complaints (hours to days later), with no context, and spend 30+ minutes just reproducing the issue.
Cost at Small Scale
Sentry free tier: $0 (5K errors/month)
UptimeRobot free tier: $0 (50 monitors)
Vercel Analytics free tier: $0 (basic Web Vitals)
Application logs: $0 (included in hosting)
Total: $0/month for an observability setup that catches 95% of production issues. The enterprise stack ($500+/month) adds: distributed tracing, custom dashboards, longer log retention, and fine-grained metrics. Useful at scale. Unnecessary for your 5000-user application.
When to Upgrade
Upgrade when: you have multiple services that interact (need distributed tracing to follow requests across services), your error volume exceeds free tier limits (good problem — means you have users), you need longer log retention for compliance, or you need custom metrics for business KPIs.
Until then: Sentry + uptime monitoring + structured logs covers everything you need. Start simple. Add complexity when real needs arise, not prophylactically.
Written by AIDToolStack Editorial
The AIDToolStack editorial team reviews developer tools, AI products, and MCP servers with hands-on testing and honest assessments. We use the tools we review every day in production.
References & Further Reading
Related Posts
Sponsor Our Newsletter
Reach thousands of developers who are actively evaluating AI tools, MCP servers, and dev infrastructure. Our weekly newsletter goes to engaged technical decision-makers.
All sponsored content is clearly labeled per our editorial policy.