Full monitoring stack for $0: Uptime Kuma for uptime, Sentry for errors, Grafana Cloud for metrics. Setup guide and free tier limits explained.
Get new posts delivered to your inbox. No spam, unsubscribe anytime.
My side project went down for nine hours on a Saturday. I didn't know until Monday morning when a user emailed me. Nine hours. No alert. No notification. Nothing. I had zero monitoring because monitoring tools cost money and I was cheap.
That was the last time. I now run a full monitoring stack — uptime checks, error tracking, metrics dashboards, and alerting — across all my projects. Total monthly cost: $0.
The application monitoring market hit $9.85 billion in 2025 and is growing at 15% CAGR. Datadog, New Relic, and Dynatrace dominate this market. They're also expensive. Mid-sized teams routinely spend $50K-100K+ per year on Datadog alone, with enterprise deployments exceeding $500K.
But here's what the enterprise monitoring vendors don't want you to know: for solo developers, small teams, and side projects, you can build a monitoring stack that covers 90% of what you need for literally zero dollars. The tools are Grafana Cloud, Uptime Kuma, and Sentry's free tier. Together they give you metrics, uptime monitoring, error tracking, and alerting.
Here's exactly how to set it up.
Downtime costs small businesses $137 to $427 per minute. That sounds like enterprise FUD, but think about what it actually means. Your SaaS app is down for 2 hours? That's $16,440 to $51,240 in lost revenue and productivity. Your e-commerce site goes down during a sale? You're losing actual orders.
Even for side projects, downtime has costs. Not in dollars, but in users who leave, credibility you lose, and SEO rankings that drop (Google notices when your site returns 500 errors).
The three things you need to monitor are:
| Layer | Question | Tool |
|---|---|---|
| Uptime | Is my app reachable? | Uptime Kuma |
| Errors | Are users hitting bugs? | Sentry |
| Metrics | How is my app performing? | Grafana Cloud |
Let me walk through each one.
Uptime Kuma is a self-hosted monitoring tool that checks whether your services are up. It's open source, has over 65,000 GitHub stars, and runs in a single Docker container using about 256MB of RAM.
What it monitors:
It checks every 20 seconds (configurable) and sends alerts through 90+ notification channels including Telegram, Discord, Slack, Email (SMTP), Pushover, and webhooks.
If you have Docker installed, this is the entire setup:
# docker-compose.yml
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: always
ports:
- "3001:3001"
volumes:
- uptime-kuma-data:/app/data
environment:
- TZ=UTC
volumes:
uptime-kuma-data:
docker compose up -d
Open http://your-server:3001, create an admin account, and add your first monitor. The whole process takes about 5 minutes from zero to your first uptime check.
You need somewhere to run this Docker container. Options:
The point is that Uptime Kuma itself costs $0. You just need somewhere to run a Docker container.
For a typical web app, I set up these monitors:
| Monitor | Type | Interval | Alert After |
|---|---|---|---|
| Main site (homepage) | HTTPS | 60s | 2 consecutive failures |
| API health endpoint | HTTPS | 30s | 1 failure |
| Database connectivity | TCP (port 5432) | 60s | 2 failures |
| SSL certificate | HTTPS cert check | 24h | 14 days before expiry |
The health endpoint is important. Don't just check if your homepage loads — check if your backend can actually reach its database and dependencies. A simple health check route:
// src/app/api/health/route.ts
import { NextResponse } from 'next/server'
import { sql } from '@/lib/db'
export async function GET() {
try {
await sql`SELECT 1`
return NextResponse.json({
status: 'ok',
timestamp: new Date().toISOString(),
})
} catch {
return NextResponse.json(
{ status: 'error', message: 'database unreachable' },
{ status: 503 }
)
}
}
Uptime Kuma also gives you a public status page — a shareable URL that shows your services' uptime history. Useful for transparency with users and it looks professional.
You might be wondering: why not just use UptimeRobot or Better Stack's free tier? Fair question. Here's the comparison:
| Feature | Uptime Kuma | UptimeRobot (Free) | Better Stack (Free) |
|---|---|---|---|
| Monitors | Unlimited | 50 | 10 |
| Check interval | 20 seconds | 5 minutes | 3 minutes |
| Notification channels | 90+ | Email, SMS | Email, Slack |
| Status pages | Unlimited | 1 | 1 |
| Data retention | Unlimited (your storage) | 2 months | 1 month |
| SSL monitoring | Yes | Pro only | Yes |
| TCP/DNS/Ping | Yes | Pro only | Limited |
| Cost | $0 (self-hosted) | $0 | $0 |
| Self-hosted | Yes | No | No |
The trade-off is clear: Uptime Kuma gives you more of everything, but you have to host it yourself. UptimeRobot and Better Stack are zero-maintenance but severely limited on free tiers. For me, the 20-second check interval alone is worth the Docker container. Five minutes is an eternity when your payment API is down.
The worst monitoring setup is one where alerts go to an email inbox nobody checks. Configure Uptime Kuma to alert through whatever you actually look at. For me, that's Telegram:
Now when something goes down, my phone buzzes in 30 seconds. Not an email I'll see tomorrow. A notification I see immediately.
Uptime tells you that something broke. Sentry tells you what broke, where in your code, and who was affected.
Sentry's Developer plan (free tier) gives you 5,000 errors and 10,000 performance transactions per month with 30-day data retention. For side projects and small apps, that's more than enough.
When an error happens in your app — an unhandled exception, a failed API call, a crash — Sentry captures:
This is fundamentally different from checking your server logs. Logs tell you "something threw an error." Sentry tells you "this specific function on line 47 threw a TypeError because the API returned null instead of an object, and it's affecting 23% of your users on mobile Chrome."
Sentry has a wizard that does most of the work:
npx @sentry/wizard@latest -i nextjs
This creates the config files, adds the SDK to your project, and sets up source maps. After running the wizard, your sentry.client.config.ts looks like:
import * as Sentry from '@sentry/nextjs'
Sentry.init({
dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
tracesSampleRate: 0.1, // 10% of transactions for performance
replaysSessionSampleRate: 0, // Session replay off on free tier
replaysOnErrorSampleRate: 0.1, // 10% replays on errors
})
Two tips for staying within the free tier:
tracesSampleRate to 0.1 or lower. You don't need 100% of performance transactions. 10% gives you a representative sample.beforeSend to filter noise. Ignore bot errors, browser extension conflicts, and known third-party issues:Sentry.init({
dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
tracesSampleRate: 0.1,
beforeSend(event) {
// Ignore errors from bots and crawlers
const userAgent = event.request?.headers?.['user-agent'] || ''
if (/bot|crawler|spider/i.test(userAgent)) return null
// Ignore ResizeObserver errors (browser noise)
if (event.message?.includes('ResizeObserver')) return null
return event
},
})
5,000 errors sounds like a lot until you have a bug that fires on every page load. One bad deployment can burn through your monthly quota in hours.
My approach: set up a Sentry alert that fires when your error count hits 3,000 (60% of your quota). That gives you time to react before you hit the cap. Also, use Sentry's "ignore" feature aggressively on errors you've decided aren't actionable.
Uptime Kuma tells you if your app is reachable. Sentry tells you about errors. Grafana Cloud tells you everything in between: response times, request rates, memory usage, database query performance.
Grafana Cloud's free plan includes:
| Resource | Free Limit |
|---|---|
| Metrics (active series) | 10,000 |
| Logs | 50 GB |
| Traces | 50 GB |
| Users | 3 |
| Metric retention | 13 months |
| Log/trace retention | 30 days |
These limits are generous for small projects. 10,000 active metric series covers a lot — most simple web apps generate a few hundred series at most.
Don't try to monitor everything. Start with these five metrics:
These five metrics will catch 90% of performance issues before users notice them.
If you're running on Vercel, you get basic Web Vitals metrics automatically. For custom metrics, you can use the OpenTelemetry SDK to push data to Grafana Cloud:
// instrumentation.ts
import { NodeSDK } from '@opentelemetry/sdk-node'
import { OTLPMetricExporter } from '@opentelemetry/exporter-metrics-otlp-http'
import { PeriodicExportingMetricReader } from '@opentelemetry/sdk-metrics'
const sdk = new NodeSDK({
metricReader: new PeriodicExportingMetricReader({
exporter: new OTLPMetricExporter({
url: process.env.GRAFANA_OTLP_ENDPOINT,
headers: {
Authorization: `Basic ${Buffer.from(
process.env.GRAFANA_INSTANCE_ID + ':' + process.env.GRAFANA_API_KEY
).toString('base64')}`,
},
}),
exportIntervalMillis: 60000,
}),
})
sdk.start()
For simpler setups, Grafana Cloud also supports Prometheus-format metrics, and many platforms (Railway, Fly.io, Render) can export metrics directly to Grafana.
If OpenTelemetry feels like overkill (and for many small projects, it is), you can start even simpler. Grafana Cloud offers a browser-based "Connections" wizard that generates config snippets for your specific stack. For a Node.js app, you can use the Grafana Alloy agent to scrape a Prometheus-compatible /metrics endpoint. Or just start with the pre-built integrations for popular services like PostgreSQL, Redis, and NGINX — they come with dashboards included.
Grafana's strength is dashboards. Once metrics are flowing in, you build panels that visualize them. The community has thousands of pre-built dashboards you can import — search the Grafana dashboard library for your stack.
For a Next.js app, I start with four panels:
The dashboard builder is drag-and-drop. You don't need to write code. The learning curve is in PromQL (the query language for Prometheus metrics), but basic queries are straightforward.
Here's how the three tools work together in practice:
Uptime Kuma pings your app every 30 seconds. If it goes down, you get a Telegram/Discord/Slack alert within 60 seconds.
Sentry catches every unhandled error in your frontend and backend. You get an email/Slack notification for new errors. You see exactly which line of code failed and how many users are affected.
Grafana Cloud shows you the big picture. Response times creeping up? Memory usage climbing? Request rate spiking? You see it on the dashboard before it becomes an outage.
| Tool | What It Catches | Alert Speed | Free Limit |
|---|---|---|---|
| Uptime Kuma | App down, SSL expiring, DNS failure | 30-60 seconds | Unlimited (self-hosted) |
| Sentry | Runtime errors, crashes, performance issues | Instant | 5,000 errors/month |
| Grafana Cloud | Performance degradation, resource usage trends | Configurable | 10K series, 50GB logs |
The gap in this stack? No centralized log aggregation by default. Grafana Cloud does give you 50GB of free logs, but shipping logs to it requires extra setup (Promtail, Alloy, or Loki). For most small projects, I skip centralized logging and rely on my hosting platform's built-in log viewer (Vercel, Railway, Fly.io all have this). When I need to investigate something, I check Sentry for the error, then look at the host logs for context.
The workflow in practice looks like this:
That's the power of layered monitoring. Each tool answers a different question, and together they tell the full story.
How does this $0 stack compare to the paid options?
| Feature | Free Stack (Ours) | Datadog ($23+/host/mo) | Better Stack ($25+/mo) | New Relic (Free-$49+) |
|---|---|---|---|---|
| Uptime monitoring | Uptime Kuma (unlimited) | Synthetic monitoring | Built-in | Built-in |
| Error tracking | Sentry (5K/mo) | Built-in | 100K errors/mo | Built-in |
| Metrics/dashboards | Grafana Cloud (10K series) | Built-in | Limited | 100GB ingest |
| Log aggregation | 50GB (Grafana) | 10GB ($1.27/GB after) | 3GB free | 100GB free |
| Alerting | All three tools | Built-in | Built-in | Built-in |
| Setup time | 2-3 hours | 30 minutes | 30 minutes | 30 minutes |
| Monthly cost | $0 | $100-500+ | $25-100+ | $0-200+ |
The paid tools are easier to set up and give you a unified experience. That matters for teams. But for solo developers and side projects, the free stack gives you 90% of the functionality at 0% of the cost.
Here's the order I'd do everything:
Saturday morning (1 hour):
Saturday afternoon (1-2 hours):
4. Add your main endpoints to Uptime Kuma (homepage, API health, SSL check)
5. Configure notifications — at minimum, email and one chat integration (Telegram, Discord, or Slack)
6. Run npx @sentry/wizard@latest -i nextjs in your project
7. Set tracesSampleRate to 0.1 and add the beforeSend filter for noise
Sunday morning (1 hour): 8. Connect your app to Grafana Cloud (OpenTelemetry or platform-native export) 9. Import a starter dashboard or build the four basic panels 10. Set up Grafana alerts for response time exceeding your threshold (I use 2 seconds for p95)
Ongoing (5 minutes/week): 11. Review Sentry errors weekly — triage, resolve, or ignore 12. Glance at Grafana dashboards for trends 13. Check Uptime Kuma's status page to see uptime percentage
Total setup time: one weekend. After that, it runs itself. I've spent more time setting up a Jira board than this entire monitoring stack takes to deploy. The ROI is absurd: a few hours of work for peace of mind that lasts as long as your app does.
Paid monitoring tools are a tax on engineering teams. Not because they're bad — Datadog is genuinely excellent software. But because most teams pay for features they don't use, dashboards nobody looks at, and data retention nobody needs.
The three-tool free stack I described covers what actually matters: is the app up, are users hitting errors, and is performance degrading? If you can answer those three questions, you can catch 90% of production issues before users complain.
The remaining 10% — deep distributed tracing across microservices, advanced anomaly detection, massive log analysis — is where paid tools earn their price. But you don't need that for a startup, a side project, or a small team. You need it when you have 50+ services, hundreds of engineers, and SLAs that demand five-nines uptime.
I've run this exact stack on three production projects for over a year. Total cost: $0. Total production incidents caught early: probably a dozen. Total hours saved compared to finding bugs through user complaints: too many to count.
Stop paying for monitoring you don't need. Stop running unmonitored apps because "monitoring is expensive." It's not. Set up these three tools this weekend and sleep better knowing you'll be the first to know when something breaks.
When your app does break — and it will, because every app does — you'll know in 30 seconds, not 9 hours. You'll have a stack trace, a timeline, and metrics showing exactly what happened. That's not a $50K enterprise feature. That's three free tools and a Saturday afternoon.
Not your users. You.