I shipped a feature on a Friday afternoon. Nothing complicated, a webhook handler that triggered a background job. Tested it locally, looked good. Deployed and moved on.
On Monday morning I opened my inbox and found seventeen emails from users reporting that nothing had happened after they completed a specific action. The action that my new webhook handled. The feature had been silently failing for the entire weekend. No errors surfaced in my dashboard because I did not have one. No alerts fired because I had not set any up. The only signal was seventeen unhappy users.
I spent Monday and Tuesday rebuilding trust that had taken months to earn. The actual bug fix took forty minutes.
That experience taught me something that no tutorial or course had ever made clear: the cost of a production incident for a solo developer is not just the downtime. It is the context switch out of whatever you were building, the frantic diagnosis without proper tooling, the user emails you have to answer personally, and the momentum you spent weeks building that evaporates in a weekend.
Shipping fast, which is the right strategy in 2026, only works if production stays stable enough that you can keep shipping. Observability is the thing that makes that possible.
The Momentum Tax Nobody Talks About
There is a concept I think about a lot when I build alone: the momentum tax.
When a production incident pulls you out of deep work, you do not just lose the time it takes to fix the bug. You lose the state you were holding in your head. The design decisions you were working through. The context you had built up. Rebuilding that takes hours, sometimes days, after even a short incident.
Research on context switching suggests that it takes an average of twenty-three minutes to fully return to deep focus after an interruption. A two-hour production incident on a Tuesday morning does not cost you two hours. It costs you Tuesday.
For solo developers, this is compounded by the fact that you are also the on-call engineer, the support team, the person answering the emails, and the one explaining to users why their workflow broke. Enterprise teams spread this load across five or ten people. You absorb all of it.
The goal of production observability for a solo developer is not to achieve five nines of uptime. It is to know about problems before your users do, fix them before they compound, and get back to building without losing a day to a two-hour incident.
Why AI-Generated Code Changes the Observability Math
If you have been shipping fast with AI coding tools, you already know the productivity gains are real. Claude Code, Cursor, GitHub Copilot, they have genuinely changed how much a solo developer can build. What is less talked about is what this means for production reliability.
Fifty-one percent of GitHub commits are now AI-assisted, according to data from 2026. That is not a criticism. It is just a fact that changes how production systems behave.
AI-generated code tends to handle the happy path very well. The common cases, the expected inputs, the standard flows. Where it is measurably weaker is edge cases, error handling, and the kinds of subtle interactions that only reveal themselves when real users do unexpected things in unexpected sequences.
Studies measuring code quality in AI-assisted codebases have found a thirty-five to forty percent increase in bug density compared to purely human-written code, particularly in error handling paths and boundary conditions. The technical debt implications of this are real and worth understanding.
This does not mean you should stop using AI tools. It means your observability setup needs to compensate for the parts AI code tends to get wrong. Specifically: you need good error tracking, not just uptime monitoring. The difference matters.
Observability vs Monitoring: What You Actually Need
These terms get used interchangeably but they represent different things.
Monitoring asks: is the system up? Is the response time within threshold? Is the error rate below a certain percentage? Monitoring tells you that something is wrong.
Observability asks: why is the system behaving this way? What happened right before the error? Which user triggered it and what were they doing? Observability tells you what is wrong and, more importantly, gives you the information to fix it quickly.
For a solo developer, you need both, but they have different priorities.
Uptime monitoring is table stakes. If your service is down, you need to know before your users do. This is easy and cheap to set up.
Error tracking is where the real value is. When your webhook handler silently fails, uptime monitoring will not catch it if the server is still responding with 200s. Error tracking catches the exception that gets swallowed, the validation that fails silently, the background job that errors out without surfacing anywhere.
Distributed tracing, tracking a request as it moves through your system, is valuable once you have multiple services or asynchronous workflows. For a simple application, structured logs serve most of the same purpose at much lower complexity.
The three things you actually need as a solo developer are: error tracking, uptime monitoring, and structured logs. In that priority order.
The Solo Developer Observability Stack Under $30 Per Month
You do not need Datadog. You do not need a dedicated SRE to manage your observability infrastructure. Here is a practical stack that covers the important bases without a complex setup or a large monthly bill.
Error tracking: Sentry free tier or GlitchTip
Sentry's free tier handles five thousand errors per month, which is more than enough for most early-stage solo products. It captures exceptions automatically, shows you the stack trace, includes the user context, and lets you set up alerts that fire when new error types appear.
GlitchTip is an open-source Sentry alternative. If you already have a VPS or a small server running, you can self-host it for essentially free. The setup takes about an hour and the savings compound over time.
For most solo developers, start with Sentry free. If you start hitting limits, evaluate GlitchTip self-hosted.
Uptime monitoring: Better Stack or Uptime Kuma
Better Stack has a free tier that checks your endpoints every three minutes and sends you an alert when something goes down. The free plan covers a handful of monitors, which is enough for most solo products.
Uptime Kuma is an open-source alternative you can self-host. Same deal as GlitchTip: if you have a server, it costs you nothing. The UI is clean and it handles all the standard check types.
Logging: Your framework's built-in logger plus a log aggregator
Structured logs are more useful than unstructured ones. A log entry that includes { "event": "webhook_failed", "userId": "abc123", "reason": "invalid_signature", "timestamp": "..." } is something you can query. A log line that says webhook failed is not.
For log aggregation, Grafana Cloud has a free tier that ingests a reasonable amount of logs. If you are already using Vercel, their log drains push logs to external providers. Logtail, part of Better Stack, integrates cleanly with both.
Total monthly cost for this stack: zero to fifteen dollars depending on whether you self-host or use managed free tiers.
Catching AI-Generated Code Breaking in Production
Standard error tracking catches exceptions. But a meaningful portion of AI-generated code failures are not exceptions. They are silent wrong answers, missed validations, and edge cases that return success codes while producing incorrect results.
This is where you need to think beyond generic monitoring and add application-specific assertions.
The most practical approach is adding explicit validation to the outputs of operations you care about, especially the ones your agentic coding workflows generated. If a function is supposed to return a user object, assert that the returned object has the required fields before using it. If a background job is supposed to create a record, verify that the record was created and log if it was not.
async function processWebhook(payload: WebhookPayload): Promise<void> {
const result = await createJobFromWebhook(payload);
if (!result.jobId) {
logger.error('webhook_processing_failed', {
payloadType: payload.type,
userId: payload.userId,
reason: 'missing_job_id_after_creation'
});
// Alert, do not silently continue
throw new Error(`Webhook processing produced no job ID for user ${payload.userId}`);
}
logger.info('webhook_processed', {
payloadType: payload.type,
userId: payload.userId,
jobId: result.jobId
});
}
This pattern does two things. It prevents silent failures from propagating silently. And it gives you rich context in your error tracker when something does go wrong.
For AI features specifically, where your application calls an LLM and acts on the response, add validation on the AI output before using it. AI-generated structured data should be parsed against a schema. If parsing fails, that is an error worth capturing, not a case to silently ignore. And quality regressions in AI output rarely surface as exceptions at all, which is exactly why pairing observability with a dedicated AI evaluation loop is the only way to catch silent drift before users feel it.
A Stripped-Down Incident Response Playbook for Solo Teams
Enterprise incident management frameworks assume you have an incident commander, a communications lead, and multiple engineers to coordinate. When you are the only developer, you need a simpler playbook that you can actually follow under pressure.
Here is the one I use.
Step 1: Detect. Your alert fires or a user reports a problem. Write down the time it started. Do not skip this step even when you are panicked. The time a problem started is the most useful piece of information you have for diagnosing it.
Step 2: Assess scope. Before you start debugging, spend two minutes understanding how bad the problem is. Is one user affected or all users? Is it a specific feature or the entire product? Is revenue being directly impacted? The answer to these questions determines how urgently you drop everything else.
Step 3: Communicate first, then fix. If this affects users, update your status page or send a brief message before you start debugging. "We are aware of an issue with X and are investigating." This takes thirty seconds and dramatically reduces the volume of inbound support messages while you work.
Step 4: Look at the logs before you look at the code. Your first instinct will be to open the code. Your error tracker and logs will get you to the problem faster. What was the last successful event before the errors started? What changed around that time?
Step 5: Fix the immediate problem, not the root cause. In a production incident, your job is to restore service. If you can revert a recent deploy, do that. If you can disable a feature flag, do that. The root cause analysis comes after service is restored.
Step 6: Write a post-mortem, even a short one. After the dust settles, spend fifteen minutes writing down what happened, when it started, what caused it, and how you will prevent a recurrence. A simple text file works. The value is not the document itself. It is the act of thinking through the sequence clearly.
Setting Up OpenTelemetry Without a DevOps Background
OpenTelemetry is the open standard for collecting traces, metrics, and logs from your application. It is vendor-agnostic, which means you can switch between backends without rewriting your instrumentation.
For a solo developer, the main reason to care about OpenTelemetry is that it works with most modern frameworks out of the box, and it means you are not locked into paying for a specific vendor's SDK to get observability data out of your application.
The simplest setup for a Node.js application looks like this:
const sdk = new NodeSDK({
traceExporter: new OTLPTraceExporter({
url: process.env.OTEL_EXPORTER_OTLP_ENDPOINT
}),
instrumentations: [getNodeAutoInstrumentations()]
});
sdk.start();
That configuration auto-instruments HTTP requests, database queries, and other standard operations. You point it at a backend, Grafana Cloud, Honeycomb, or a self-hosted Jaeger instance, and you start getting traces without writing a single custom span.
The self-hosted path, running Loki for logs, Grafana for dashboards, and Tempo for traces on a small VPS, costs around five to ten dollars per month in infrastructure and gives you a complete observability stack with no per-seat pricing.
For solo developers on a budget who are already running a server for their application, this is worth exploring. For solo developers who want managed infrastructure with no ops overhead, Grafana Cloud's free tier handles a reasonable amount of data.
The Post-Mortem That Actually Helps
Post-mortems have a reputation for being bureaucratic exercises that large engineering organizations do to feel like they have process. For solo developers, a short post-mortem after a significant incident is genuinely valuable.
The questions that produce useful insights:
What was the first signal that something was wrong? Was it an alert, a user email, or you manually checking? If it was a user email, that is information about a gap in your monitoring.
How long between when the problem started and when you knew about it? The longer this gap, the more users experienced the problem. Reducing this gap is the most impactful thing you can do.
What information did you have to find manually that should have been in your logs or error tracker? Every time you had to grep logs or add a debug statement to understand the incident, that is something to build into your instrumentation.
What change could prevent this category of problem from happening again? Not every incident warrants a code change. Some warrant an alert. Some warrant a monitoring check. Some just warrant writing down what you learned.
The format does not matter. A Notion page, a Markdown file in your repo, a voice memo you transcribe later. The act of writing it down is the part that makes you better at this.
Common Mistakes Solo Developers Make With Monitoring
The mistakes I made and have watched other solo developers make follow predictable patterns.
Setting up monitoring only after something breaks. The first production incident is often the motivation to finally set up error tracking. Setting it up before gives you a baseline and makes the first incident easier to diagnose.
Alert fatigue from over-monitoring. Configuring alerts on everything generates enough noise that you start ignoring alerts. Pick the things that require action and alert on those. Everything else goes in the logs for later review.
Treating all incidents as equally urgent. A single user hitting an edge case in a rarely-used feature is not the same as all users being unable to log in. Triage before you sprint. Spending four hours on a low-impact bug while a high-impact one goes unnoticed is a common failure mode.
Not using the free tier of tools before paying for them. Sentry, Better Stack, Grafana Cloud: all have free tiers that cover most solo developer needs. Start there. Upgrade when you actually hit limits, not when you anticipate you might someday.
Skipping structured logging because it feels like extra work. Unstructured logs are difficult to search and nearly useless during an incident when you need to find specific events quickly. Adding a consistent log format early pays dividends every time something breaks.
What to Set Up This Week
If you have a live product with no observability, here is the practical sequence to get meaningful coverage without spending a weekend on infrastructure.
Day one. Sign up for Sentry free tier. Add the SDK to your application. Deploy. You now have error tracking. This is the single highest-leverage thing you can do.
Day two. Sign up for Better Stack or Uptime Kuma. Add a monitor for your production URL and your most critical API endpoints. Set up an email or Slack alert. You now have uptime monitoring.
Day three. Add structured logging to your most critical flows. The ones that handle payments, user sign-ups, and any integrations with third-party services. These are the paths where silent failures hurt the most.
Day four. Write a one-paragraph incident response checklist and put it somewhere you will find it when you are panicking. The checklist does not need to be comprehensive. It just needs to slow you down long enough to think before you start making changes under pressure.
Day five. Set up a status page. Instatus and Statuspage both have free tiers. Having a public place to communicate during incidents reduces inbound support volume and signals to users that you take reliability seriously.
That is five days of setup for a monitoring stack that will catch most problems before they compound. None of it requires DevOps expertise. All of it is free or close to it.
The Honest Bottom Line
The vibe coding revolution has made it genuinely possible for solo developers to ship at a pace that was impossible a few years ago. But shipping fast creates more surface area for things to break. The developers who sustain that pace are the ones who invest in catching problems quickly, not the ones who ship and hope.
Observability is not a production luxury. For a solo developer, it is the thing that determines whether a two-hour bug costs you forty minutes or costs you Tuesday.
Set up error tracking today. Add uptime monitoring this week. The fifteen minutes it takes to install Sentry is worth considerably more than the seventeen user emails you will otherwise receive on Monday morning.
Start with the basics. They cover ninety percent of the problems you will actually face.
