Monitoring is how you know your app is broken before your users tell you. Without it, you find out about outages from complaints, you have no idea why a feature stopped working, and you can't tell if a slow query is affecting everyone or just one person.
If Cartara flagged this in your diff, you likely added error tracking, logging, metrics, or alerting to your app.
The Three Pillars
Logs
A timestamped record of events — what happened, when, and to whom. Logs are your primary tool for diagnosing incidents after the fact.
Example: "At 14:32, user ID 4821 triggered a payment and received a 500 error from the Stripe API."
Metrics
Numerical measurements over time — counts, rates, percentages, durations. Metrics tell you about trends and aggregate health.
Example: "API response time averaged 240ms this morning but jumped to 1,800ms at 2pm."
Traces
A record of a single request's journey through your system — which functions were called, in what order, and how long each took.
Example: "This request took 1,800ms total: 20ms in the route handler, 1,750ms waiting for the database."
For small apps, you'll mostly work with logs and metrics. Traces become useful as your system grows more complex.
What to Monitor
Uptime — is your app reachable? The most fundamental thing. Set up an uptime monitor before you launch.
Error rate — what percentage of requests are failing? A spike is almost always a signal that something just broke. Aim for under 1% error rate.
Response time — how long does your app take to respond? Users notice slowdowns before they notice errors.
- Under 200ms feels instant
- 200ms–1s is acceptable
- Over 1s users start noticing
- Over 3s users start leaving
Database performance — slow queries are the most common cause of app slowdowns. Watch query duration and look for outliers.
API spend — for paid APIs (OpenAI, Stripe), monitor spend in real time and set budget alerts.
Essential Tools for Small Apps
UptimeRobot — Uptime Monitoring
Pings your app every 5 minutes and alerts you (email, SMS, Slack) if it goes down. Free for up to 50 monitors. Takes 5 minutes to set up.
Set this up before you launch. It's the single most important monitoring tool.
Sentry — Error Tracking
Captures every unhandled error with full context — stack trace, user info, what they were doing. Groups similar errors together and alerts on new issues. Free up to 5,000 errors/month.
Sentry gives you a real-time feed of everything going wrong. Without it, you're guessing.
Platform Logs and Metrics
Most hosting platforms (Vercel, Railway, Render, Supabase) include basic request volume, response time, and log viewing in their dashboards. Check these weekly.
PostHog — Product Analytics
Tracks what users actually do in your app — which features they use, where they drop off, how long they stay. Also includes session recordings. Free up to 1M events/month.
This bridges the gap between "is the app working" and "are users succeeding." You might have zero errors but still have a broken onboarding flow that no one completes.
What You'll See in Your Code
Monitoring integration typically appears in diffs as:
Sentry initialization in your app entry point:
```ts
import * as Sentry from '@sentry/nextjs';
Sentry.init({ dsn: process.env.SENTRY_DSN, tracesSampleRate: 0.1 });
```
Structured logging — JSON objects rather than plain strings:
```ts
// ❌ Hard to search
console.log("Payment failed for user 4821: card declined");
// ✅ Structured, searchable
logger.error({ event: 'payment_failed', userId: 4821, reason: 'card_declined' });
```
Custom error reporting:
```ts
try {
await processPayment(userId);
} catch (error) {
Sentry.captureException(error, { extra: { userId } });
throw error;
}
```
Alerting
Monitoring only helps if you get notified when something is wrong. But too many alerts train you to ignore them.
Alert on symptoms users experience: app is down, error rate spiked, login is broken — not on every internal signal.
Set meaningful thresholds: alert when error rate exceeds 2% for more than 5 minutes, not when a single request is slow.
Use the right channel:
- Critical (app is down) → SMS or phone call
- Urgent (elevated errors) → Slack or email
- Informational (usage trends) → daily digest or dashboard
A Simple Incident Response Checklist
When something goes wrong:
- Check uptime — is the whole app down or just one feature?
- Check Sentry — is there a new error class? What's the stack trace?
- Check recent deploys — did something just get pushed?
- Check your hosting platform's status page — is the outage on their end?
- Roll back the last deploy if nothing else is obvious
Most early-stage incidents are caused by a bad deploy or a third-party service outage.