--- title: How to Diagnose Production Bugs When You Can't Reproduce... description: Production-only bugs are notoriously hard to diagnose because the issue is usually the environment, not the code. A systematic approach starts with gathering... canonical: https://daily.dev/posts/how-to-diagnose-production-bugs-when-you-can-t-reproduce-them-locally-kxdnllwui twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: How to Diagnose Production Bugs When You Can't Reproduce Them Locally | daily.dev og:description: Production-only bugs are notoriously hard to diagnose because the issue is usually the environment, not the code. A systematic approach starts with gathering... og:url: https://daily.dev/posts/how-to-diagnose-production-bugs-when-you-can-t-reproduce-them-locally-kxdnllwui og:image: https://api.daily.dev/og/posts/KXDnLLwUI.png og:image:alt: How to Diagnose Production Bugs When You Can't Reproduce Them Locally og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # How to Diagnose Production Bugs When You Can't Reproduce Them Locally **[freeCodeCamp](https://daily.dev/sources/freecodecamp)** · 21 min read · 2 upvotes · 0 comments ## Summary Production-only bugs are notoriously hard to diagnose because the issue is usually the environment, not the code. A systematic approach starts with gathering evidence before touching code: check when the issue began, whether it followed a deployment, and which users are affected. Meaningful structured logs with request context, metrics via Prometheus/Grafana, and distributed tracing with OpenTelemetry/Jaeger are the core tools. To reproduce production bugs, containerize the app, define infrastructure as code, use realistic data, and simulate concurrent traffic. When isolating causes, change only one variable at a time. A concrete ASP.NET Core example shows how a missing environment variable causes a NullReferenceException in production but not locally. The post also argues that much debugging difficulty is self-inflicted infrastructure overhead, and that PaaS platforms reduce this by centralizing logs, metrics, deployment history, and tracing out of the box. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why does an application work fine locally but throw a NullReferenceException in production when reading an environment variable? A missing environment variable is a common cause: calling a method like ToLower() on a null value returned by Environment.GetEnvironmentVariable crashes the request. This happens when the deployment forgets to define a variable such as REGION, which was always set on developer machines but omitted during deployment. The fix is providing a default value with the null-coalescing operator and comparing case-insensitively. _Track down configuration-driven bugs like this by following practical debugging workflows on daily.dev._ ### How do you use distributed tracing to find which microservice is causing a slow checkout request? A distributed trace breaks a request into spans, one per service call or database query, each recording start time and duration, so a waterfall view immediately shows which span consumed most of the total time. For example, a 4.61 second checkout trace can reveal that 4.29 seconds occurred inside a single inventory database query while the gateway, auth, and payment services stayed healthy, avoiding hours of investigating the wrong component. OpenTelemetry provides the open standard and instrumentation libraries for implementing this across languages. _Developers debugging slow multi-service requests can find tracing techniques like this on daily.dev._ ### How do I isolate which environment difference is causing a bug that only happens in production? Change only one variable at a time rather than several at once, so a failure can be attributed to a single cause with confidence. For example, if production differs from development in database version, memory limit, and an environment variable, test each difference separately in a container: run Postgres 16 alone, then cap memory at 512MB alone, and observe which change alone reproduces the crash before drawing conclusions. _Engineers chasing elusive environment-specific bugs can find structured troubleshooting approaches on daily.dev._ ## Similar posts on daily.dev - [The Bug That Made Me Question Reality for a Few Hours](https://daily.dev/posts/the-bug-that-made-me-question-reality-for-a-few-hours-ndxvzfmjj) · DEV · 157 upvotes · 13 comments - [Why "It Worked on My Machine" Still Happens in 2026](https://daily.dev/posts/why-it-worked-on-my-machine-still-happens-in-2026-wu83ivzac) · freeCodeCamp · 49 upvotes · 2 comments - [Working software runs locally](https://daily.dev/posts/working-software-runs-locally-acfymodik) · Lobsters · 0 upvotes · 0 comments - [How to build workflows that catch bugs early and keep code moving](https://daily.dev/posts/how-to-build-workflows-that-catch-bugs-early-and-keep-code-moving-48fwi8kod) · Dynatrace · 0 upvotes · 0 comments --- Tags: [#devops](https://daily.dev/tags/devops), [#observability](https://daily.dev/tags/observability) [View this post on daily.dev](https://daily.dev/posts/how-to-diagnose-production-bugs-when-you-can-t-reproduce-them-locally-kxdnllwui) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"How to Diagnose Production Bugs When You Can't Reproduce Them Locally","url":"https://daily.dev/posts/how-to-diagnose-production-bugs-when-you-can-t-reproduce-them-locally-kxdnllwui","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/how-to-diagnose-production-bugs-when-you-can-t-reproduce-them-locally-kxdnllwui"},"datePublished":"2026-07-24T23:05:10.649Z","dateModified":"2026-09-14T07:02:32.352Z","description":"Production-only bugs are notoriously hard to diagnose because the issue is usually the environment, not the code. A systematic approach starts with gathering...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/11f6f98114761340acb8e2cd2f697c32?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/11f6f98114761340acb8e2cd2f697c32?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"freeCodeCamp","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"freeCodeCamp","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1628412854/logos/freecodecamp","url":"https://daily.dev/sources/freecodecamp"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/how-to-diagnose-production-bugs-when-you-can-t-reproduce-them-locally-kxdnllwui","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"devops,observability","timeRequired":"PT21M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"freeCodeCamp","item":"https://daily.dev/sources/freecodecamp"},{"@type":"ListItem","position":3,"name":"How to Diagnose Production Bugs When You Can't Reproduce Them Locally"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/how-to-diagnose-production-bugs-when-you-can-t-reproduce-them-locally-kxdnllwui#faq","mainEntity":[{"@type":"Question","name":"Why does an application work fine locally but throw a NullReferenceException in production when reading an environment variable?","acceptedAnswer":{"@type":"Answer","text":"A missing environment variable is a common cause: calling a method like ToLower() on a null value returned by Environment.GetEnvironmentVariable crashes the request. This happens when the deployment forgets to define a variable such as REGION, which was always set on developer machines but omitted during deployment. The fix is providing a default value with the null-coalescing operator and comparing case-insensitively. Track down configuration-driven bugs like this by following practical debugging workflows on daily.dev."}},{"@type":"Question","name":"How do you use distributed tracing to find which microservice is causing a slow checkout request?","acceptedAnswer":{"@type":"Answer","text":"A distributed trace breaks a request into spans, one per service call or database query, each recording start time and duration, so a waterfall view immediately shows which span consumed most of the total time. For example, a 4.61 second checkout trace can reveal that 4.29 seconds occurred inside a single inventory database query while the gateway, auth, and payment services stayed healthy, avoiding hours of investigating the wrong component. OpenTelemetry provides the open standard and instrumentation libraries for implementing this across languages. Developers debugging slow multi-service requests can find tracing techniques like this on daily.dev."}},{"@type":"Question","name":"How do I isolate which environment difference is causing a bug that only happens in production?","acceptedAnswer":{"@type":"Answer","text":"Change only one variable at a time rather than several at once, so a failure can be attributed to a single cause with confidence. For example, if production differs from development in database version, memory limit, and an environment variable, test each difference separately in a container: run Postgres 16 alone, then cap memory at 512MB alone, and observe which change alone reproduces the crash before drawing conclusions. Engineers chasing elusive environment-specific bugs can find structured troubleshooting approaches on daily.dev."}}]} ```