Handbook
/
Product & Engineering
Monitoring and Observability for Early Startups
You can't fix what you can't see. Here's how to set up monitoring that catches problems before users report them.
Every startup reaches the moment: your product is down, users are complaining, and you have no idea what’s wrong. Without monitoring, you’re flying blind.
Live Services Are Living
Production systems aren’t “set and forget.” They’re living organisms that require ongoing care, attention, and feeding.
Services need:
•
Regular check-ins (not just when alerts fire)
•
Dependency updates and security patches
•
Capacity adjustments as usage changes
•
Configuration tuning based on real behavior
•
Proactive maintenance before things break
The mindset shift:
Shipping to production isn’t the end—it’s the beginning. A feature launched without monitoring, without maintenance plans, without ownership clarity isn’t really shipped. It’s abandoned.
Signs of a neglected service:
•
Dependencies months or years out of date
•
No one knows how it works
•
Alerts disabled because they were “noisy”
•
Documentation describes a different system
•
“It works, don’t touch it” culture
What healthy ownership looks like:
•
Someone is responsible for this service’s health
•
Regular reviews of error rates and performance
•
Proactive upgrades, not just reactive fixes
•
Runbooks that reflect current reality
•
The service gets better over time, not worse
Treat your production systems like you’d treat anything else that’s alive: they need attention, care, and someone who notices when they’re not doing well.
But observability is a deep field, and startups don’t have time for enterprise-grade setups. Here’s the minimum viable monitoring that catches problems before they become disasters.
The Three Pillars
Observability traditionally has three pillars:
Logs: Records of what happened. “User 123 logged in at 10:30.”
Metrics: Aggregated measurements. “Average response time is 150ms.”
Traces: End-to-end request paths. “This request went from API → Database → Cache → Response.”
For early startups, focus on logs and metrics. Add tracing when you have complex distributed systems.
What to Monitor
Availability
Is your product up? This is the most basic question.
Monitor:
•
HTTP endpoints returning 200
•
Database connections working
•
Background jobs running
•
Third-party services responding
Alert: Immediately when any critical service goes down.
Errors
What’s breaking?
Monitor:
•
Error rates (errors per minute)
•
Error types (4xx vs 5xx, specific exceptions)
•
Error trends (increasing? Stable?)
Alert: When error rate exceeds normal baseline.
Performance
Is it fast enough?
Monitor:
•
Response time (p50, p95, p99)
•
Database query time
•
External API latency
•
Page load time (frontend)
Alert: When latency degrades significantly.
Business Metrics
Is the product working?
Monitor:
•
Signups
•
Activations
•
Revenue
•
Key feature usage
Alert: When metrics deviate from normal patterns.
Infrastructure
Is the system healthy?
Monitor:
•
CPU, memory, disk usage
•
Queue depths
•
Connection pools
•
Rate limits
Alert: When approaching capacity limits.
Tools to Use
Error Tracking
Sentry is the standard. It captures errors, stack traces, and context automatically.
Setup:
import * as Sentry from '@sentry/node';
Sentry.init({
dsn: 'YOUR_DSN',
environment: process.env.NODE_ENV,
});
Sentry will catch and report uncaught exceptions, and you can manually capture errors:
try {
riskyOperation();
} catch (error) {
Sentry.captureException(error);
// handle error
}
Uptime Monitoring
External checks that your site is reachable:
•
Better Uptime
•
UptimeRobot
•
Pingdom
•
Checkly
Configure checks for:
•
Homepage
•
Key API endpoints
•
Login flow
•
Critical user journeys
Logging
Logtail, Logflare, or Papertrail for log aggregation. Your platform (Vercel, Fly, AWS) likely has built-in logging too.
Structured logging helps:
// Bad
console.log('User logged in');
// Good
logger.info('user_login', {
userId: user.id,
email: user.email,
timestamp: Date.now(),
});
Structured logs can be searched and aggregated.
Application Performance Monitoring (APM)
Full observability platforms:
•
Datadog – Comprehensive but expensive
•
New Relic – Similar to Datadog
•
Grafana Cloud – Good if you like building dashboards
•
PostHog – Combines product analytics with some observability
For startups, Sentry + uptime monitoring + platform logs is often enough. Add full APM when complexity demands it.
Product Analytics
Track what users do:
•
Amplitude, Mixpanel – Full-featured analytics
•
PostHog – Open source, self-hostable
•
Plausible, Fathom – Simple, privacy-focused web analytics
At minimum, track:
•
Signups
•
Feature usage
•
Conversion events
•
Churn indicators
Setting Up Alerts
Alert Principles
Alert on symptoms, not causes. Alert when the API is slow, not when CPU is high. High CPU that doesn’t affect users isn’t urgent.
Alert on user impact. Would this affect users? If not, it might be informational but not urgent.
Avoid alert fatigue. Too many alerts means they get ignored. Only alert on things that require immediate action.
Define response procedures. When this alert fires, what do you do? Document it.
Essential Alerts
These alerts matter for every startup:
1.
Site down – Any critical endpoint unreachable
2.
Error spike – Error rate exceeds baseline
3.
Latency degradation – Response time significantly slower
4.
Database issues – Connection failures, slow queries
5.
Queue backup – Background jobs not processing
Alert Routing
Where do alerts go?
•
Slack/Email for warnings and low-priority
•
PagerDuty/Opsgenie for critical alerts that need immediate response
•
On-call rotation when you have multiple people
For small teams, a single founder on-call with phone alerts is fine.
Building Dashboards
A single dashboard showing system health:
Include:
•
Request rate (is traffic normal?)
•
Error rate (are things breaking?)
•
Latency (is it slow?)
•
Top errors (what’s breaking?)
•
Database performance
•
Key business metrics
Keep it simple. One screen you can glance at to know if things are healthy.
Common Patterns
Healthcheck Endpoint
Create an endpoint that verifies critical dependencies:
app.get('/health', async (req, res) => {
const checks = {
database: await checkDatabase(),
redis: await checkRedis(),
stripe: await checkStripe(),
};
const healthy = Object.values(checks).every(c => c.ok);
res.status(healthy ? 200 : 503).json(checks);
});
Point uptime monitors at this endpoint.
Request Logging Middleware
Log every request for debugging:
app.use((req, res, next) => {
const start = Date.now();
res.on('finish', () => {
logger.info('request', {
method: req.method,
path: req.path,
status: res.statusCode,
duration: Date.now() - start,
userId: req.user?.id,
});
});
next();
});
Error Boundaries (Frontend)
Catch React errors before they crash the whole app:
class ErrorBoundary extends React.Component {
componentDidCatch(error, errorInfo) {
Sentry.captureException(error, { extra: errorInfo });
}
render() {
if (this.state.hasError) {
return <ErrorFallback />;
}
return this.props.children;
}
}
Debugging Production Issues
When something breaks:
1.
Check alerts and dashboards. What’s the symptom?
2.
Check error tracking. What specific errors are occurring?
3.
Check logs. What was happening around that time?
4.
Check recent deploys. Did something change?
5.
Check dependencies. Are third-party services having issues?
6.
Reproduce if possible. Can you trigger the error?
Having good observability means you spend minutes, not hours, finding root causes.
Mistakes to Avoid
No monitoring until it’s too late. Set up basics before you need them.
Monitoring everything. Noise obscures signal. Focus on what matters.
Not testing alerts. Alerts that don’t fire when they should are useless.
Sensitive data in logs. Don’t log passwords, tokens, or PII.
Alert fatigue. If you ignore alerts, they’re not working.
The Minimum Setup
For a startup just getting started:
1.
Sentry for error tracking
2.
Better Uptime for availability monitoring
3.
Platform logs (Vercel, Railway, etc.) for debugging
4.
One dashboard showing key metrics
5.
Alerts for down and error spikes
This takes a few hours to set up and catches 90% of issues before users report them.
Key Takeaways
•
Monitor availability, errors, performance, and business metrics
•
Use Sentry for errors, uptime monitor for availability
•
Alert on symptoms and user impact, avoid alert fatigue
•
Build one dashboard for at-a-glance health checks
•
Create a healthcheck endpoint that tests dependencies
•
Log requests and errors with structured data
•
Set up basics before you need them—it’s too late during an incident
AIMake has access to all of this
Our AI has access to the entire Startup Handbook. Ask it anything about building your startup.
Get started →
← Previous
Building for Mobile vs Web vs Both
Next →
Prioritization Frameworks That Actually Work