Monitoring Your App for Free: Sentry, Uptime Kuma, and Grafana on a Budget

You spent weeks building your application. You wrote tests, fixed the CSS, deployed it to a server, and shared the link with your friends. Then you went to sleep. While you slept, the database connection pool ran out, every request started returning 500 errors, and nobody told you. By morning, your app had been broken for seven hours. You had no idea because you had no monitoring.

This is not a hypothetical scenario. It happens to developers every single day. The good news is that setting up production-grade monitoring costs exactly $0 per month if you know which tools to use and how to combine them. This guide walks you through the entire setup — from error tracking to uptime checks to metrics dashboards — using only free tools and free tiers.

1. Why Monitoring Matters

Deploying without monitoring is like flying without instruments. You might be fine on a clear day, but the moment something goes wrong — and it will go wrong — you are completely blind. You do not know what broke, when it broke, or how many users it affected. You find out when someone sends you an angry message or when you happen to check the site yourself.

Professional monitoring is built on three pillars of observability. Understanding these three pillars is the foundation for everything else in this guide.

The Three Pillars of Observability

Metrics are numbers measured over time. Response time is a metric. CPU usage is a metric. The number of active users right now is a metric. Metrics answer the question "how much?" and "how fast?" They are cheap to store and easy to alert on. When someone says "our p95 response time is 200ms," they are talking about a metric.

Logs are event records. Every time your application does something — handles a request, catches an error, connects to a database — it can write a log entry. Logs answer the question "what happened?" They are the most detailed form of observability. A single request might generate dozens of log entries as it flows through your application. The challenge with logs is volume: a busy application can generate gigabytes of logs per day.

Traces are request journeys. A trace follows a single request as it moves through your entire system — from the user's browser, to your API server, to your database, to a third-party service, and back. Traces answer the question "where did this request spend its time?" If a page load takes 3 seconds, a trace shows you that 50ms was your API, 2,400ms was a slow database query, and 550ms was a call to a payment provider. Without traces, you would just know "it is slow" but not why.

What Happens Without Monitoring

Here is what actually happens to applications that have no monitoring in place:

• Silent failures. A background job that sends welcome emails crashes. No one notices for two weeks. 3,000 new users never received their welcome email. You find out when a user complains on Twitter.
• Slow degradation. Your database queries get 10% slower every week as the data grows. By month three, pages take 8 seconds to load. You lose 40% of your traffic before you realize it because you never measured baseline performance.
• Undetected errors. A third-party API you depend on starts returning errors for 5% of requests. Those 5% of users see a broken page. Your error rate has been quietly climbing for days but you have no error tracking to tell you.
• Blind deployments. You push a new release that introduces a memory leak. The server runs out of memory 6 hours later and crashes. Without resource monitoring, you do not connect the crash to your deployment.

Every one of these scenarios is preventable with basic monitoring. And every tool you need is available for free.

2. Error Tracking with Sentry

Sentry is the most widely used error tracking platform in the industry, and its free tier is genuinely generous. You get 5,000 errors per month, which is more than enough for a personal project, a startup MVP, or a student portfolio. If your app is producing more than 5,000 errors per month, you have bigger problems than monitoring costs.

What Sentry Does

When an unhandled exception occurs in your application — a TypeError, a failed API call, a database connection error — Sentry captures it automatically. But it does not just capture the error message. It captures the full stack trace, the environment variables, the browser and OS of the user, the URL they were visiting, and something called breadcrumbs.

Breadcrumbs are a chronological trail of events that happened before the error occurred. They might show: user clicked "Submit" button, HTTP POST to /api/orders started, database query to check inventory executed, and then the error occurred. This context is invaluable for debugging because the error message alone rarely tells you the full story. Knowing what the user did in the 30 seconds before the crash is often the difference between a 5-minute fix and a 5-hour investigation.

Sentry also supports source maps, which means your minified production JavaScript errors show the original file names, line numbers, and variable names instead of cryptic references to bundle.js line 47,293. For frontend applications, this alone is worth using Sentry.

Beyond error tracking, Sentry's free tier includes basic performance monitoring and release tracking. Performance monitoring shows you the slowest transactions in your application. Release tracking lets you see which deployment introduced a new error, so you can quickly decide whether to roll back.

Setup: 5 Lines of Code

Setting up Sentry is remarkably simple. After creating a free account at sentry.io, you install the SDK for your language and add a few lines of initialization code.

For Node.js applications:

For Python applications:

The tracesSampleRate of 0.2 means Sentry captures performance data for 20% of requests. On the free tier, this keeps you well within limits while giving you enough data to spot trends. You can set it to 1.0 during development to capture everything.

Configuring Alerts

By default, Sentry sends you an email for every new error. This is useful at first, but once your app has traffic, you should configure smarter alerts. In the Sentry dashboard, go to Alerts and create rules like:

• New issue alert: Notify when an error type is seen for the first time. This catches newly introduced bugs immediately after a deployment.
• Regression alert: Notify when an error you previously marked as resolved comes back. This catches regressions.
• Spike alert: Notify when the error rate exceeds a threshold (for example, more than 50 errors in 5 minutes). This catches cascading failures.

Sentry supports email, Slack, Microsoft Teams, PagerDuty, and webhook notifications. For a free setup, email and Slack webhooks cover most needs.

3. Uptime Monitoring with Uptime Kuma

Uptime monitoring answers the most basic question: is your application currently reachable? If your server goes down at 3 AM, an uptime monitor detects it within seconds and sends you a notification. Without one, you rely on users to tell you — and most users do not bother. They just leave.

Commercial uptime monitoring services like Pingdom ($10/month), StatusCake, and UptimeRobot work fine, but they all have limited free tiers. Uptime Kuma is a completely free, self-hosted alternative that matches or exceeds the features of paid services. It has over 60,000 stars on GitHub and is actively maintained.

Deployment: One Docker Command

If you have a server with Docker installed (a $4/month VPS from any cloud provider, or even a Raspberry Pi on your home network), you can run Uptime Kuma with a single command:

That is it. Open http://your-server-ip:3001 in a browser, create an admin account, and you have a fully functional uptime monitoring dashboard. The -v flag ensures your data persists across container restarts.

What You Can Monitor

Uptime Kuma supports multiple monitoring types, which makes it far more than a simple "is the website up" checker:

• HTTP(s) monitoring: Checks if a URL returns a successful response. You can specify expected status codes (200, 301), check for specific keywords in the response body, and set timeout thresholds. This is your primary monitor for web applications.
• TCP port monitoring: Checks if a specific port on a server is accepting connections. Use this for databases (port 5432 for PostgreSQL, 3306 for MySQL), Redis (port 6379), or any custom service.
• DNS monitoring: Verifies that your domain name resolves correctly. If someone accidentally changes your DNS records, this catches it.
• Ping monitoring: Basic ICMP ping to check if a server is reachable on the network. Simple but effective for infrastructure monitoring.
• Docker container monitoring: Connects to the Docker socket and checks if specific containers are running. Useful if you deploy with Docker Compose.

Status Pages

Uptime Kuma includes a built-in status page feature. You can create a public page (for example, status.yourapp.com) that shows the current status of all your services. This is the same kind of page you see at status.github.com or status.aws.amazon.com. When something goes down, users can check the status page instead of flooding your inbox with "is it just me?" emails. You can customize the status page with your branding, group services into categories, and add incident descriptions.

Alerting

Uptime Kuma supports over 90 notification methods. The most practical free options are:

• Email (SMTP): Use a free Gmail or Outlook SMTP server to send alerts to your inbox.
• Slack webhook: Create a free Slack workspace for your project and send alerts to a #monitoring channel.
• Discord webhook: If your team uses Discord, alerts can post directly to a channel. Setup takes 30 seconds.
• Telegram bot: Create a bot with @BotFather, get a chat ID, and receive instant mobile notifications for free.

4. Metrics and Dashboards with Grafana

Sentry tracks errors. Uptime Kuma tracks availability. But neither tells you the full performance story. For that, you need metrics — numbers measured over time, displayed on dashboards, with alerts when they cross thresholds. Grafana is the industry standard for metrics visualization, and its cloud offering has a genuinely useful free tier.

Grafana Cloud Free Tier

Grafana Cloud gives you the following at no cost:

• 10,000 metrics series — enough for multiple services reporting dozens of metrics each
• 50 GB of logs — enough for months of log data from a small to medium application
• 50 GB of traces — enough to capture distributed traces across your services
• Unlimited dashboards — build as many visualizations as you want
• Alerting included — email and webhook alerts based on metric thresholds

To put these numbers in perspective, a typical Node.js application reporting standard metrics (request rate, response time, error rate, memory usage, CPU, event loop lag) uses about 30–50 metric series. You could monitor 200 services before hitting the 10,000 series limit.

The Prometheus + Grafana Stack

If you prefer self-hosting (for privacy, control, or learning), the Prometheus + Grafana stack is completely free and is the industry standard used by companies of every size. Here is how it works:

Prometheus is a time-series database that collects metrics. Your application exposes a /metrics endpoint that returns metrics in a simple text format. Prometheus scrapes (pulls data from) that endpoint at a regular interval, typically every 15 seconds, and stores the data.

Grafana connects to Prometheus as a data source and lets you build dashboards to visualize the metrics. You get line graphs, gauges, tables, heatmaps, and more.

Run docker compose up -d and you have Prometheus at port 9090 and Grafana at port 3000. Log in to Grafana (default admin/admin), add Prometheus as a data source (URL: http://prometheus:9090), and start building dashboards.

Key Metrics to Track

Not all metrics are equally useful. Here are the ones that actually matter for application monitoring:

Metric	What It Measures	Alert Threshold
Response time (p50)	Median response time — half of requests are faster	> 300ms
Response time (p95)	95th percentile — the "slow request" experience	> 1,000ms
Response time (p99)	99th percentile — the worst experience	> 3,000ms
Error rate	Percentage of requests returning 5xx errors	> 1%
Uptime	Percentage of time the service is reachable	< 99.9%
Database query time	Average time for DB queries to complete	> 100ms
Memory usage	Percentage of available RAM in use	> 85%
CPU usage	Percentage of CPU capacity in use	> 80%
Disk space	Percentage of disk in use	> 90%

Why percentiles (p50, p95, p99) instead of averages? Because averages hide problems. If 99 requests take 50ms and 1 request takes 10,000ms, the average is 149ms — which looks fine. But 1% of your users are waiting 10 seconds. Percentiles expose these outliers. The p95 tells you the response time that 95% of users experience or better. That is the number that actually reflects user experience.

Building Your First Dashboard

A practical monitoring dashboard has four rows:

• Row 1 — Service status: Green/red indicators for each service. Is the API up? Is the database up? Is the cache up? This row gives you a one-second health check.
• Row 2 — Request metrics: Line graphs showing request rate (requests per second), response time (p50 and p95), and error rate over the last 6 hours. These three graphs tell you if your app is handling traffic well.
• Row 3 — Error details: A table of the top 10 errors in the last hour, grouped by error type and endpoint. This points you directly to what needs fixing.
• Row 4 — Resource usage: Gauges for CPU, memory, and disk. These tell you if your server is approaching capacity limits.

5. Health Checks and Structured Logging

Monitoring tools need something to check. The foundation of external monitoring is the health check endpoint — a simple route in your application that returns its current status. And the foundation of internal observability is structured logging — writing logs in a format that machines can parse and search.

Implementing Health Check Endpoints

A health check endpoint is a route (typically GET /health or GET /healthz) that your monitoring tools hit at regular intervals. If it returns a 200 status, the app is healthy. If it returns 500 or times out, something is wrong.

A basic health check just confirms the process is running. A better health check verifies that the application can actually do its job — that it can reach the database, the cache, and any critical external services.

Node.js / Express example:

This endpoint returns a response like:

Point your Uptime Kuma HTTP monitor at this endpoint. Now you are not just checking if the server process is running — you are checking if the application is actually functional. If the database goes down, the health check returns 503, Uptime Kuma detects it, and you get a notification within seconds.

Structured Logging

Most beginners log like this:

This is human-readable but machine-hostile. You cannot search for all errors. You cannot filter by user. You cannot correlate events from the same request. Structured logging solves this by using JSON format with consistent fields:

This produces JSON logs that look like:

Log Levels

Use log levels consistently across your application:

• ERROR: Something broke and needs immediate attention. A request failed, data was lost, or a critical service is unreachable. Alert on these.
• WARN: Something unexpected happened but the application recovered. A retry succeeded, a fallback was used, or a deprecated feature was called. Review these periodically.
• INFO: Normal operational events. A user logged in, an order was created, a scheduled job completed. Useful for understanding what happened.
• DEBUG: Detailed diagnostic information. Function arguments, intermediate calculation results, cache hit/miss. Only enable in development or when actively debugging a production issue.

Correlation IDs

A correlation ID is a unique identifier assigned to each incoming request and passed along to every log entry, database query, and downstream service call generated by that request. When something goes wrong, you search your logs by correlation ID and instantly see every event related to that single request — even across multiple services.

Include req.correlationId in every log entry for that request. When a user reports a bug and shares their correlation ID (returned in the response header), you can trace the entire request journey through your logs in seconds.

6. The Complete Free Monitoring Stack

Now let us put everything together. Here is the complete $0/month monitoring stack, what each tool handles, and how they connect.

The Stack

Tool	Purpose	Cost	Free Tier Limits
Sentry	Error tracking + performance	$0	5,000 errors/month, 10K transactions
Uptime Kuma	Uptime + status pages	$0 (self-hosted)	Unlimited monitors
Grafana Cloud	Dashboards + alerting	$0	10K metrics, 50 GB logs, 50 GB traces
Prometheus	Metrics collection	$0 (self-hosted)	Unlimited
Better Stack	Log management + incidents	$0	1 GB logs, 5 monitors

You do not need all of these. For a single application, Sentry + Uptime Kuma + Grafana Cloud covers everything. Prometheus is for self-hosters who want full control. Better Stack is for teams who want managed log search without running Grafana themselves.

What to Alert On

Alerting is where monitoring becomes actionable. But alerting wrong is almost as bad as not alerting at all. Here is what deserves a notification versus what should just show up on a dashboard:

Alert immediately (send a push notification or Slack message):

• Service is down (Uptime Kuma detects failure for more than 2 minutes)
• Error rate exceeds 5% for more than 5 minutes
• Response time p95 exceeds 3 seconds for more than 10 minutes
• Database connection pool is exhausted
• Disk usage exceeds 90%
• Memory usage exceeds 90% sustained for 5 minutes
• SSL certificate expires in less than 7 days

Show on dashboard only (review during working hours):

• New error types appearing after a deployment
• Response time slowly increasing over days
• Warning-level log entries
• CPU usage above 60%
• Cache hit rate dropping

Avoiding Alert Fatigue

Alert fatigue is the single biggest monitoring mistake teams make. It works like this: you set up monitoring and create alerts for everything. Your phone buzzes 20 times a day with low-priority notifications. After a week, you start ignoring them. After a month, you mute the channel entirely. Then a critical alert fires and you miss it because it drowns in the noise.

Here is how to prevent alert fatigue:

• Only alert on things that require action. If you get an alert and your response is "I will look at it later," it should not be an alert. It should be a dashboard metric.
• Use time-based thresholds. Do not alert if CPU spikes to 90% for 10 seconds — that is normal during deployments. Alert if CPU is above 85% sustained for 5 minutes.
• Group related alerts. If the database goes down, you will get alerts for the DB, every API endpoint, the health check, and the error rate. Configure your tools to group these into one incident, not five separate notifications.
• Review and prune alerts monthly. Look at every alert that fired in the last 30 days. If any alert fired more than 10 times without leading to action, either fix the underlying issue or raise the threshold.
• Separate critical and warning channels. Use two Slack channels: #alerts-critical (muted during sleep only) and #alerts-warning (checked once a day). Or use different notification priorities on your phone.

Setting Up Free Notifications

All three major chat platforms support free incoming webhooks:

Sentry, Uptime Kuma, and Grafana all support these webhook URLs natively. You configure them once and every tool can send alerts to the same channel.

Common Monitoring Mistakes

Even with the right tools, these mistakes undermine your monitoring:

• Monitoring only uptime, not performance. Your app can be "up" but completely unusable if every page takes 15 seconds to load. Monitor response times, not just availability.
• No logging in production. As mentioned earlier, some developers turn off logging in production. When something breaks, they have zero information about what happened. Keep structured logging enabled at the INFO level at all times.
• Not monitoring the database. Most application performance problems are actually database problems. A missing index, a slow query, or a connection pool that is too small. Monitor query execution time and connection pool usage. These two metrics catch 80% of database issues.
• Monitoring too many things. A dashboard with 50 graphs is as useless as no dashboard. Start with the five most important metrics: uptime, error rate, response time (p95), CPU, and memory. Add more only when you have a specific reason.
• Not testing alerts. Set up an alert and never verify it fires correctly. Use Uptime Kuma's "Test" button for notifications. Create a test alert in Grafana. Confirm you actually receive the notifications before you need them in a real emergency.