3 AM. Your Phone Buzzes.
Your API is throwing 500 errors. You’re groggy. You SSH into the server and see:
Error: Cannot read property 'userId' of undefined at /app/routes/orders.js:47
That’s… not helpful. What request caused this? What was the input? What was in the database record it was processing? You have no idea.
You grep the logs. Nothing useful. You add some console.logs. Deploy. Wait for it to happen again. It does, 10 minutes later, with a slightly different error you didn’t plan for.
This is the standard way indie hackers debug production APIs. And it sucks.
There’s a better way.
The Problem With Standard Error Handling
Express gives you error handlers. They’re fine:
app.use((err, req, res, next) => {
console.error(err);
res.status(500).json({ error: 'Something went wrong' });
});
You catch the error. You log it. The user gets a 500.
But here’s what you don’t have:
- What HTTP headers came in? (auth tokens, user IDs, etc.)
- What was the request body?
- What previous middleware already ran?
- What database records were loaded before the error?
- What was the full call stack, not just the error message?
You’re blind. Your error handler is a black box.
The Better Way: Context + Observability
What you actually need:
- Full request context when an error happens
- Database query history (what queries ran before the error?)
- Middleware chain (what already executed?)
- User/auth context (who was this request for?)
Standard logging won’t cut it. You need distributed tracing.
How It Works With Tracekit
Instead of logging errors in isolation, you trace the entire request. When an error happens, you see the full journey:
POST /api/orders → Error: Cannot read property 'userId'
│
├─ Auth middleware → ✓ User verified (user_id: 123)
├─ Load user from DB → ✓ Found user record
├─ Validate order data → ✓ Valid
├─ Load inventory from DB → ✓ In stock
├─ Process payment → ✓ Charged $49.99
├─ Create order record → ✗ Error occurred here
│ Error: Cannot read property 'userId' of undefined
│ Stack: /app/routes/orders.js:47 in createOrder()
│
└─ Request context:
├─ User ID: 123
├─ Order: { items: [...], total: 49.99 }
├─ Payment: { txnId: "ch_123...", status: "succeeded" }
└─ Request Headers: { auth: "Bearer ...", ... }
Everything is captured. You see what happened before the error. You see the exact user, exact order, exact payment status.
You fix the bug in 5 minutes instead of spending 30 minutes grasping in the dark.
Real Example: The Payment Bug
You’re processing orders. Occasionally, orders get charged but fail to insert into the database. Your error handler catches it:
Error: Cannot read property 'userId' of undefined
Without Tracekit:
- Check database logs
- See the payment went through ($50 charged)
- See the order insertion failed
- Grep error logs for similar errors
- Deploy with more logging
- Wait for it to happen again
- Look at the new logs
- Realize the issue: sometimes `order.userId` is undefined
- Fix: Add a null check, deploy
- Total time: 45 minutes, customer is confused, manual refund needed
With Tracekit:
- Open Tracekit dashboard
- Click the failed request
- See the full request trace:
- Auth user: correctly set to 123
- Order object received: { items: […], userId: undefined }
- Payment succeeded: $50 charged
- Insert failed: no userId
- Realize: the client sent `user_id` (snake_case) but your code expects `userId` (camelCase)
- Fix: Add request transformation middleware, deploy
- Total time: 8 minutes, no refund needed, customer never notices
Setting Up Tracekit for Express
Takes 2 minutes:
npm install @tracekit/node-apm
// At the very top of your app
const tracekit = require('@tracekit/node-apm');
tracekit.init({
apiKey: process.env.TRACEKIT_KEY,
serviceName: 'my-api',
environment: process.env.NODE_ENV,
});
const express = require('express');
const app = express();
// Your middleware and routes...
// Error handler (now with tracing)
app.use((err, req, res, next) => {
// Tracekit automatically captures the full context
console.error(err);
res.status(500).json({
error: 'Something went wrong',
traceId: req.traceId // Send trace ID to client for support
});
});
That’s it. Every request is traced. Every error is captured with full context.
What Gets Captured Automatically
- Request metadata: Method, path, headers, status code, duration
- Database queries: Time, SQL, rows affected
- External API calls: URL, method, response time, status
- Errors: Full stack trace, request context, variable values
- Middleware execution: Order and timing of each middleware
- User context: auth tokens, user ID, session data
The Dashboard
Once you’ve deployed, open your Tracekit dashboard:
- Requests tab — See all requests, sorted by duration or error status
- Click a failed request — Full timeline, every step
- Error details — Variable values, request context, full stack trace
- Filter by error type — See patterns (“all 500s are in the payment endpoint”)
No searching logs. No grep. No deploying with debug code.
When You Actually Need This
- Your API has >100 requests/day in production
- You’ve had 3+ production incidents you couldn’t debug quickly
- Your current solution is “add console.logs and redeploy”
- You support customers and need to investigate issues without SSH-ing
- You want to reduce MTTR (mean time to resolution) from hours to minutes
Free Tier Gets You Started
- 200k traces/month — Covers ~6k requests/day
- Completely free — No credit card
- Real production visibility — Not a limited demo
That’s enough to run a side project or bootstrap an MVP.
Try It Free
Deploy the SDK today. Next time you get a 500 error at 3 AM, you’ll know exactly what happened.
Next: Performance Monitoring for APIs
Once you’ve solved the debugging problem, the next challenge is performance. Why are some requests taking 5+ seconds? (Hint: it’s not always what you think.)
Questions?
- Docs: https://app.tracekit.dev/docs
- Need help? DM @osayawe_terry on Twitter or email: [email protected]
Subscribe for more: Next week, we’re covering “The Hidden Performance Bugs in Your Express API” (and how to find them in 5 minutes).
