I Found Out About Production From a Customer Email

The email arrived at 6:14 a.m. Subject line: "Your app charged me twice." I was half awake, convinced it was a scam, until I opened Stripe and saw two identical checkout sessions for the same customer within ninety seconds. My code had a race on the success page. I had no idea until she wrote me.

That is the solo founder version of observability. Not a Datadog war room. Not a PagerDuty rotation with six people. One tired builder learning that production is a different country from localhost, and the natives email you when you break their card.

I had logs. Vercel showed function invocations. I could grep if I felt sporty. What I did not have was error monitoring for a micro-SaaS solo founder setup: grouped exceptions, release tags, and an alert that fired when the checkout handler threw before a human opened Gmail. I fixed the double charge, refunded her, and spent the next weekend doing what I should have done before customer number two: wire Sentry, tag releases from GitHub Actions, and treat Stripe billing paths like load-bearing walls.

This post is the boring infrastructure chapter nobody posts on Twitter. You already know how to ship. You maybe already read about CI/CD for solo founders and analytics when you are the only reader. Error monitoring sits between those: it tells you when the thing you shipped is on fire in ways tests did not predict. I am not selling you a platform. I am selling you a short list of routes to instrument, alert rules that respect sleep, and a weekly five-minute habit so bugs stop arriving as surprises in the inbox.

Some numbers here are rounded examples. Some scenes are composite. The double charge was real enough to change how I ship.

The build stage of a micro-SaaS is where engineers feel clever. Error monitoring is where you find out whether that cleverness survived contact with real cards, real time zones, and real people who do not read your docs. I would rather ship a smaller feature with monitoring on the checkout path than ship a wide feature surface nobody can pay for because a silent exception guard-railed the button. That tradeoff feels un-sexy until the first refund request lands before your first coffee.

Error monitoring micro saas solo founder: the gap between green builds and angry users

Production looks fine from the deploy dashboard. The build passed. Preview URL worked on your laptop. You clicked checkout once with a test card and it felt fine. Then a user in Germany hits an old Android browser, your client bundle throws before the Stripe redirect, and they bounce without telling you. Your MRR graph does not move. Your error graph would scream. If you had one.

Error monitoring micro saas solo founder reality is simple: you are the on-call team, the triage nurse, and the person who writes the fix. Enterprise observability assumes someone filters noise before it reaches a human. You do not get that luxury. Every alert lands on the same phone that also gets Stripe payout notifications and your mom's group chat. That is why the goal is not "capture everything." The goal is capture the exceptions that correlate with lost money, lost trust, or lost accounts, and ignore the rest on purpose.

Think of three layers. Prevention: tests and preview deploys from CI/CD. Detection: grouped errors with stack traces and release tags. Interpretation: tie spikes to analytics drops or support tickets. Most solo founders stop at prevention and wonder why customers still know about bugs first. Prevention is necessary. It is not sufficient.

I treat monitoring like insurance on the boring parts of the stack. Not glamorous. Not a moat. Just the difference between learning about a webhook failure from Sentry and learning about it when someone's subscription silently never activated.

What error monitoring is not

It is not a replacement for talking to users. It is not a substitute for validating before you build. It will not tell you that your pricing is wrong or your headline confuses people. It tells you the checkout button threw undefined is not a function for three percent of sessions after last Tuesday's deploy. That is a narrow superpower. Narrow superpowers are what solo founders can afford to get good at.

It is also not log tailing as a lifestyle. Host logs are fine for forensics after you know something broke. They are terrible as a dashboard. You will not scroll fifteen thousand lines of JSON while making dinner. Grouped issues with counts and first-seen timestamps are how humans act.

The minimum viable promise

If you do this right, you should be able to answer four questions within five minutes of an alert: what threw, how many users hit it, which release introduced it, and which route or job owns the fix. If you cannot answer release, go fix your deploy tags before you add another alert rule. Without release correlation, you are guessing which commit to revert.

Write those four questions on a sticky note above your desk if that helps. I did for a month until the habit stuck. Now I glance at an alert the same way I glance at a failing GitHub check: something concrete to fix, not a vague cloud of dread about "the app feeling flaky." Flaky is just unmeasured.

CI/CD proves the build; it does not prove checkout works

Continuous integration is a gate on what you merge. It is not a guarantee on what users experience. I learned that the hard way when a dependency update passed TypeScript, passed lint, passed a Playwright smoke test that only covered the marketing page, and still broke the authenticated dashboard because a client-only API key was undefined in production.

Your CI/CD pipeline should stay lean: preview deploy, maybe a build check, merge to main, automatic redeploy. Keep that. Error monitoring is the sibling system that watches runtime after merge. Picture two parallel tracks. Track A: git commit to preview to green check to production deploy. Track B: production traffic hitting real environment variables, real Stripe mode, real browser matrix. Track B is where exceptions live.

Preview deploys catch a shocking amount. I am not arguing against them. I am arguing that they are user-session-shaped like your testing, not like the world. You test logged in as yourself on a MacBook. Customers test logged out on a phone they have had for four years. Monitoring closes that gap without you buying BrowserStack and running fifty profiles on every push.

When you wire both, incidents get boring in a good way. Sentry shows a spike on POST /api/stripe/webhook. You glance at GitHub, see the merge two hours ago that touched the webhook handler, revert or patch, redeploy through the same pipeline, mark the issue resolved, and go back to dinner. Without monitoring, the same incident is a support thread, a refund, and a vague sense that the product is flaky.

I keep a mental map of what CI/CD can actually prove. It proves the repository compiles on a clean machine. It proves your smoke test user can still load / and maybe click one button you remembered to script. It proves environment variables required for build exist in the CI secret store, which is not the same as existing in production. It does not prove that Stripe's API version string in your SDK matches the dashboard setting. It does not prove that a customer on a tablet in portrait mode can reach the billing portal link you emailed them. Those are runtime truths. Runtime truths need runtime sensors.

The overlap zone is worth naming explicitly because founders confuse it. Integration tests that hit Stripe test mode in CI are valuable. They catch dumb regressions in your checkout session payload. They do not catch switching test keys into a production deploy by mistake. An error monitor will catch that the moment a live card hits test keys, which is ugly but fast. I would rather get an ugly alert in minutes than a calm Stripe dashboard and silent failures for a day.

If your preview deploy uses test Stripe keys and production uses live keys, tag environments in Sentry as preview and production and never mix alert rules between them. I once got paged because a preview URL was indexed by Google and bots hammered a test checkout. That was a robots.txt problem and an environment tagging problem, not a product bug. Lesson learned cheaply.

Where tests should end

I write a handful of automated tests on money paths: checkout session creation returns a URL, webhook handler returns 200 on a fixture event, signup creates a row. I do not pretend that covers every edge case. Error monitoring is the net for everything else. The net should be small mesh, not cargo-cult full coverage.

If you are still deploying by clicking "Redeploy" in a dashboard without branch discipline, fix that first. Monitoring a chaotic deploy process is like putting a smoke detector in a house where you also leave the stove on. Order matters.

Release tags are not optional

Every production deploy should send a release identifier to your error tool. 0.42.0, git SHA, whatever you use. When an issue says "first seen in release 0.42.0," you know where to look. When it says "unknown," you are back to archaeology. Most Sentry plus Vercel or GitHub Action guides take ten minutes. Do that before you tune alert thresholds.

Logs are a pile of words until someone gets paged

Logs answer "what happened on this server at this millisecond" for someone who already knows which server and which millisecond. Errors answer "what is breaking for users repeatedly right now" for someone who has other work today.

Host logs from Vercel, Fly, or Railway are useful. I still open them when Sentry points at a function name. But logs without structure are a passive archive. Error monitoring turns exceptions into issues with fingerprints, counts, and assignees (you). That grouping is the whole product. One bug might generate four hundred events. You want one ticket, not four hundred scares.

There is a maturity ladder solo founders climb whether or not they name it. Level zero: users report bugs. Level one: you notice in logs after users report. Level two: Sentry emails you when unhandled exceptions spike. Level three: you alert on specific routes and webhook failures with thresholds. Level four: you connect spikes to PostHog funnels in a weekly review. Most of us can live at level three for years and be fine.

Structured logging still helps. If you log checkout_session_failed with a user id and plan id, your future self will hug you. But structured logs are not a substitute for capturing the stack trace when Next.js throws on the client. Client errors never hit your server logs unless you send them somewhere.

Distributed tracing is the next rung on the ladder after error grouping. OpenTelemetry, fancy span graphs, service maps: wonderful when you have twelve microservices. For a solo Next.js app, tracing is often overkill until latency on a specific API route becomes the bottleneck. Errors come first because errors directly map to refunds and churn. Latency comes later when people complain things feel slow but do not attach a stack trace.

When you do open logs, search with a hypothesis. "Did webhook handler log anything at 14:03 UTC?" not "scroll until something looks weird." Sentry gives you the timestamp and release to narrow the window. That pairing saves hours. Before I had grouping, I would find one log line and tell myself the mystery was solved. Half the time it was a red herring line from a health check.

Client versus server

Micro-SaaS stacks like Next.js blur the line. You need browser SDK for client components and Node SDK for API routes and server actions. Miss the client SDK and you fly blind on the exact place users feel pain: buttons, forms, redirects. Miss the server SDK and webhooks fail quietly while Stripe retries and your database never updates.

Start server-side on webhooks and checkout APIs because that is where money moves. Add client SDK the same week because that is where signup friction shows up. Do both before you optimize sampling rates or debate OpenTelemetry.

Sampling and noise

Free tiers limit events. Good. Constraints force discipline. Capture all unhandled exceptions on critical routes. Sample verbose breadcrumbs elsewhere if you must. Do not sample away checkout errors to save quota. If quota bites, fix the recurring bug that eats events, or pay the twenty dollars that matches your MRR.

Pick a tool you will still pay for at twelve customers

The error monitoring market is built for teams with platform engineers. You are one person who also writes marketing. Pick the tool you will actually configure on a Sunday, not the one that wins Gartner.

Sentry is the default for good reasons: Next.js docs, Vercel integration, release tracking, issue grouping that mostly works, free tier that survives early traction. GlitchTip is a compatible open-source fork if you want self-host or cheaper at scale. Better Stack and others combine logs plus uptime; fine if you want one bill, but do not let log aggregation become a second hobby.

I do not recommend rolling your own "post errors to a Discord webhook" system unless you enjoy parsing stack traces at midnight. Discord alerts are a fine supplement, not a database of issues. You need deduplication, ignore rules, and resolve workflows even when the workflow is just you clicking "resolved" so the spike does not re-notify.

Cost at twelve paying customers should be zero to twenty dollars a month. If it is more, you over-built or you have unfixed bugs spamming events. Fix the bug. That is cheaper than premium tiers.

Here is how I actually decided on Sentry instead of alternatives. I needed browser and Node in one project, release tracking with GitHub, and email alerts without configuring PagerDuty. GlitchTip checked the same boxes if I self-hosted; I did not want another box to patch. Better Stack tempted me because uptime pings and logs in one place sounded tidy. I already had uptime on my host. Splitting concerns won: Sentry for exceptions, host for raw logs when Sentry pointed me there, Stripe for money truth.

Migration between tools is annoying but not impossible. Export issues, fix the top three recurring fingerprints, update SDK init, replay deploy. Do not let tool comparison become a month-long side quest while checkout stays unmonitored. Two afternoons beats perfect vendor selection.

Self-host versus SaaS

Self-hosting Sentry or GlitchTip is a fine weekend if you like Postgres and Redis more than customers. Most solo founders should use SaaS until MRR clears a few thousand and compliance forces otherwise. Your time is the bottleneck, not the margin on monitoring.

Data residency matters for some B2B buyers. If you are not selling to them yet, do not pre-optimize. If you are, ask during sales what they need and upgrade then.

What to ignore in feature lists

Session replay, AI suggested fixes, performance monitoring at full sample rate: nice later. You are not debugging ten-second LCP on day forty; you are debugging "webhook returned 500." Turn replay on for checkout flows if your tier includes a few sessions. Do not watch replays of every visitor like a security guard.

Wire errors where money and identity actually move

Instrument in order of financial pain, not alphabetical route order. My list for a typical Stripe plus Supabase SaaS looks like this mentally: webhook handler, checkout session creation, billing portal session, signup and login, password reset, the cron that downgrades expired trials, the background job that sends receipts. Marketing pages can wait.

On Next.js App Router I split client and server. Server: wrap API route handlers so unexpected throws become captured exceptions with request context (not raw card numbers). Use Sentry's Next.js SDK so edge and node runtimes both report. Client: init once in the root layout, set environment and release, capture unhandled rejections. For server actions, follow the SDK guide so failures in actions show up with the action name instead of a anonymous stack.

Stripe webhooks deserve their own paragraph because they fail silently by design. Stripe retries. Your user sees "paid" in Stripe dashboard while your app never unlocked the feature. Wrap the handler in try/catch, report failures with event type and customer id in extras (not full payload), return non-200 only when you want retry. Alert when the same event type fails more than twice in ten minutes.

If you followed Stripe billing for micro-SaaS, you already have Customer ids and subscription rows. Link them in Sentry context when you can: stripe_customer_id, plan, user_id. When an alert fires, you can refund or comp from Stripe without playing detective.

Environment variables cause a disproportionate share of solo founder incidents. STRIPE_SECRET_KEY missing in preview but present in prod, or live key in a preview deploy someone tested real cards against. Capture configuration errors explicitly. When checkout throws because env is undefined, tag the issue config and fix the host settings before you patch code.

Concrete pattern for Next.js API routes: wrap the handler body, rethrow after capture if you need Stripe to retry webhooks, or swallow and return 200 only when safe. For checkout creation, fail loud to the client so the user sees an error instead of a spinning button. Silent failure on checkout is how you lose trials who never email you.

import * as Sentry from "@sentry/nextjs";
 
export async function POST(req: Request) {
  try {
    const body = await req.text();
    // verify signature, switch on event.type, update DB
    return new Response("ok", { status: 200 });
  } catch (err) {
    Sentry.captureException(err, {
      tags: { area: "stripe-webhook" },
    });
    return new Response("error", { status: 500 });
  }
}

That is not production-complete. It is the shape: one place failures become visible. Add event type to context once parsing succeeds. Add customer id after you look up the row. Never attach full card numbers or raw webhook secrets to context. The SDK scrubs some fields; do not rely on magic.

For client components, capture boundary errors on routes that matter. A global error boundary on the app layout catches render throws; also log failed fetches to checkout explicitly so you see network versus logic bugs separately.

Breadcrumbs without leaking secrets

Breadcrumbs are the trail before the crash: which page, which fetch, which button. Useful. Dangerous if you log passwords or tokens. Scrub PII in beforeSend hooks. Sentry documents this. Read it once. Regret less.

Cron and queue jobs

If you use Vercel cron or a worker for dunning emails, each job is a mini product surface. Unhandled throws there mean silent failures: emails not sent, trials not expired, exports stuck. Give each job a name in the monitor and alert separately from web traffic. Low volume jobs should alert on first failure, not fifth, because there may not be a fifth.

Alerts that respect a one-person on-call rotation

Alert fatigue is real when the on-call rotation is you every night. The goal is few loud alerts on money paths, everything else digested weekly.

I use three tiers in practice. P1: unhandled exception on webhook, checkout, or auth with more than one user in fifteen minutes, or any single failure on webhook signature verification. P2: client errors on signup or onboarding above a small threshold. P3: everything else, reviewed Sunday morning with coffee.

Send P1 to phone email or SMS you actually read. Send P3 to email you batch. Do not send P3 to push. You will mute the channel and miss the P1 that matters.

Thresholds matter because bots scan your site and trigger weird code paths. One error is noise. Five errors on checkout in ten minutes is signal. Tune with real traffic after a week of data, not day one paranoia.

Ignore rules are allowed. That third-party script on the blog throws on ad blockers? Ignore the domain or the message. Chronic benign errors teach you to ignore the tool. Prune them.

Sleep matters for judgment. If you wake at 3 a.m., verify the alert is real, roll back if release-tagged and obvious, otherwise acknowledge and go back to bed unless money is actively leaking. Fix properly after coffee. Heroics at midnight produce second bugs.

Escalation paths can stay manual at solo scale. Sentry issue assigned to you, GitHub issue optional, fix in branch, merge through CI/CD, resolve in Sentry when deploy finishes. You do not need Jira. You need consistency so resolved means resolved, not "I got tired of the email."

Who gets paged when you travel

Solo does not always mean alone. If a partner or contractor has repo access, document which alerts they can ack. Keep runbooks in the issue tracker or a single markdown file: webhook failure means check Stripe dashboard, check env, check recent deploy. Future you is also a contractor.

Release tags so you know which deploy broke Stripe

Monitoring without releases is a crime scene without timestamps. Wire release in CI the same day you wire the SDK.

On Vercel, connect Sentry integration so each deploy becomes a release. On GitHub Actions, add a step that runs sentry-cli releases new with the git SHA, uploads source maps for browser stacks, and finalizes on deploy success. Source maps are not optional for minified client bundles. Without them, stack traces point at chunk-482.js and you hate yourself.

Git SHA versus semver is a religious war you can skip. Use whatever your host already exposes. Vercel gives you a deployment id. npm gives you a version in package.json if you bump it, which many solo founders forget for months. I tag releases with the short SHA because it always matches git blame. Marketing version numbers can catch up later when you actually ship a changelog page.

Pair release tags with the habit of writing one-line changelog entries in merge commits. "Fix webhook idempotency" beats "updates" when you scan git during an incident.

When Sentry says a regression appeared in release abc123, check that deploy diff first. If the issue is old but newly noisy, suspect traffic mix or a third-party API change, not necessarily your last commit. Counts help distinguish.

If you use preview deploys, decide whether preview errors go to a separate Sentry project or the same project with environment tag preview. I prefer separate projects early so test noise never pages you. Merge the config when you are confident preview keys are not live Stripe.

Regression detection is the quiet superpower. Sentry can mark an issue as regression when it reappears after you resolved it. Treat regressions harsher than new bugs. Regressions mean your fix was incomplete or your test gap is still open. Write a one-line test or manual checklist item when you close a regression. "Webhook idempotency: replay same event id twice in staging."

Deploy freezes are a solo founder luxury you sometimes need anyway. If a P1 money bug is open, stop merging features until it is closed. Monitoring makes that call easier because the issue count is right there, not buried in guilt.

Source maps and secrets

Upload source maps in CI, not from the browser. Keep auth tokens in GitHub secrets. Rotate if leaked. Source maps expose your code structure; that is fine for a private repo world, weird for some compliance buyers. Cross that bridge when sales asks.

When error monitoring is too early

If you have no production URL, stop reading and go validate. Error monitoring on a localhost-only project is procrastination with dashboards.

If you have a URL but zero users, a free uptime ping plus browser console is enough. Add Sentry when you turn on real billing or when the first stranger can create data you cannot afford to lose.

If you are pre-revenue but public, still add client SDK early if signup is fragile. The cost is low. The lesson is which browsers break your UI. That is product research, not ops vanity.

The opposite mistake is waiting until you have "enough scale." Enough scale is one angry email you did not want. You do not need a formal incident response handbook. You need a DSN in production and the discipline to check the dashboard the same day you merge a risky billing change. Treat that like brushing teeth. Boring, daily, prevents expensive dental work.

The three errors worth fixing before anything else

First: anything that blocks payment or double-charges. Revenue integrity beats feature work. Refund fast, fix faster, postmortem in one paragraph you save for yourself.

Second: auth loops and session loss. If users cannot log in, nothing else matters. These show up as client errors and 401 spikes.

Third: webhook or sync failures that desync Stripe from your database. Users cancel in your app but stay billed in Stripe, or pay but stay locked out. Reconciliation scripts help; prevention helps more.

Everything else is prioritized by frequency times severity. One user hitting a typo in an edge-case export is a bug. Fifty users hitting the same export throw is the afternoon's work.

Support email is a lagging indicator. Users who bother to write are often the nice ones. Angry users churn quietly. Monitoring catches the silent majority who hit the same client error and leave. That is why I trust issue counts over inbox volume when prioritizing fixes.

Security-sensitive errors belong in the same system with stricter scrubbing. Failed auth, password reset token reuse, webhook signature failures. Alert fast, keep payloads minimal, rotate secrets if you suspect leakage. Error tools are not SIEM replacements; they are enough for solo scale until Derek's world of procurement asks for more.

Performance errors blur into monitoring. Timeouts to Stripe, database connection pool exhaustion, edge function limits on Vercel. Many show up as exceptions or as HTTP 500 without a pretty stack. Tag them infra and fix with retries, backoff, or bigger plan tiers on the host. Do not hand-wave "Stripe was slow" without a graph showing it.

A weekly five-minute error review next to analytics

Every Sunday I open three tabs: Stripe for net new MRR, PostHog or whatever I use for activation, Sentry for unresolved issues trending up. Five minutes. Not an hour of dashboard tourism.

I ask: did any error spike correlate with a funnel drop? Did new issues appear after Thursday's deploy? Did I mark issues resolved that are still happening because I muted instead of fixed? I write one sentence in a notes file. "Webhook noise gone after idempotency fix; watch signup on Safari." That sentence steers the week.

This pairs directly with micro-SaaS analytics solo founder habits. Analytics without errors is story without antagonist. Errors without analytics is noise without business impact. Together they tell you whether to fix code or fix onboarding.

When nothing is on fire, the review still runs. Closed-empty weeks are data. You are not ignoring the tool.

Compare week over week, not day over day. Traffic spikes from a Product Hunt bump or a newsletter mention will spike errors too, often harmless 404s or timeouts on pages you forgot to cache. A steady climb in checkout errors while traffic is flat is the pattern that should cancel your afternoon plans. I keep a tiny spreadsheet with columns for deploy date, new Sentry issues, and activation rate. One row per week. Fancy BI tools are overkill until someone pays you to look enterprise.

Monthly, skim which issues consumed the most events. Chronic low-grade errors eat quota and hide spikes. Fix or ignore deliberately. "Export CSV fails on empty state" might be one line of validation. Leaving it costs you signal every week.

If you hire a part-time dev later, give them Sentry access before Slack emoji privileges. The error backlog is the cheapest onboarding doc. It shows where the app is fragile without you writing a novel in Notion.

Teaching yourself to read a stack trace is a skill that pays forever. You do not need to memorize every frame. Read top and bottom, find your file names, ignore node_modules unless the bug is dependency version. Click the release, open the diff, form a hypothesis, test locally with the same env vars if possible. That loop is the job.

A few honest answers about error monitoring

Sleep is a feature your customers pay for

I still ship bugs. Everyone does. The difference between amateur and professional at solo scale is not zero defects. It is time-to-know and time-to-fix on the paths that fund the rest of the product.

Error monitoring micro saas solo founder style is unglamorous. It will not get you on a podcast. It might save you from typing a refund email while your coffee gets cold. Wire the SDK on money routes, tag releases from the same CI/CD you already built, alert like you mean to sleep, and read Sentry next to Stripe once a week.

Then go build something users can actually pay for. The boring stack is what keeps the boring SaaS profitable.

If you take one action this week, make it unglamorous: create the Sentry project, paste the DSN into your host env, deploy once with a release tag, and throw a test error in staging so you see the full loop. Delete the test issue. Smile because the next surprise in your inbox might be a payout notification instead of a bug report from a stranger who deserved better. That loop takes less time than arguing about tools on Reddit, and it pays rent faster too.