Debugging production issues is very different from debugging bugs on a local machine. In local development, you have full control: breakpoints, console logs, mock data, hot reload, and time. In production, everything is constrained. Users are impacted, logs may be incomplete, errors may be intermittent, and rolling back blindly can be risky.
This article explains how experienced web developers actually debug production issues, not in theory but in real-world practice. It is written from the perspective of Angular-based enterprise applications, but the principles apply to most modern web stacks.
The goal is to show how senior developers think, what tools they rely on, how they minimise impact, and how they prevent the same issues from happening again.
1. Understanding What “Production Debugging” Really Means
Production debugging is not about fixing code immediately. It is about:
Identifying the real problem
Reducing user impact
Avoiding data corruption
Applying the safest possible fix
Learning from the incident
A production issue usually means:
In Angular applications, common production issues include:
Blank screens after deployment
API calls failing intermittently
Memory leaks causing slowdowns
Role-based access failures
Browser-specific bugs
Build-time optimisation issues
The biggest mistake junior developers make is trying to reproduce the issue immediately without understanding the context. Senior developers slow down first.
2. First Rule: Do Not Panic, Stabilise the System
When an issue is reported in production, the first step is not debugging. It is stabilisation.
Questions to ask immediately
Is the issue affecting all users or some users?
Is it ongoing or intermittent?
Is it getting worse?
Is data integrity at risk?
Immediate actions
Disable the problematic feature if possible
Roll back to the last stable version if the issue is critical
Add feature flags if available
Inform stakeholders that the issue is being investigated
In Angular enterprise apps, feature toggles are extremely useful. Many teams use:
This allows developers to isolate the problem without rushing a fix.
3. Reading Production Errors the Right Way
Production errors are noisy. A senior developer knows how to filter signal from noise.
Sources of production errors:
Browser console errors reported by users
Centralised logging tools
Error tracking platforms
Backend logs
Infrastructure monitoring alerts
The key is correlation.
For example:
A frontend error spike started at 10:42 AM
Backend logs show increased 401 errors at the same time
A deployment happened at 10:30 AM
This immediately narrows the search.
4. Angular Production Errors: What They Look Like
Angular production builds are optimised and minified. This changes how errors appear.
Common Angular production issues:
Cannot read properties of undefined
ExpressionChangedAfterItHasBeenCheckedError (rare but possible)
Chunk loading failures
Route guard failures
Dependency injection errors after tree shaking
Minification removes variable names, so stack traces can look unreadable.
That is why source maps are critical.
5. Using Source Maps Safely in Production
Source maps allow mapping minified code back to original TypeScript.
Best practice
In Angular:
"sourceMap": {
"scripts": true,
"styles": false,
"vendor": false
}
This allows debugging without exposing sensitive code.
Senior developers rarely debug directly in production. They observe production and debug locally using source maps.
6. Logging: The Most Underrated Debugging Tool
Logs are often the only way to understand production behaviour.
Bad logging
console.log('Error occurred');
Good logging
this.logger.error('Order submission failed', {
orderId,
userId,
statusCode,
apiResponse
});
Angular logging best practices
Use a central logging service
Add context (user, route, feature)
Avoid logging sensitive data
Log intent, not just errors
Example logging service:
@Injectable({ providedIn: 'root' })
export class LoggerService {
error(message: string, context?: any) {
// send to remote logging service
}
info(message: string, context?: any) {
// info level log
}
}
Senior developers think ahead: “If this fails in production, what will I need to know?”
7. Reproducing the Issue Without Guessing
The hardest part of production debugging is reproduction.
Steps senior developers follow
Identify exact user flow
Capture browser, device, role, and data conditions
Check feature flags
Use production-like data locally
Match API versions and configs
They do not randomly try things.
In Angular apps, issues often depend on:
Lazy-loaded modules
Route guards
Role-based templates
Change detection timing
Reproducing with realistic data volume is critical.
8. Browser DevTools in Production Context
Senior developers know browser DevTools deeply.
Useful techniques
Network tab to inspect failing APIs
Throttling to simulate slow networks
Checking request headers
Inspecting localStorage and sessionStorage
Watching memory usage
For Angular:
Many production issues are network or caching related, not code bugs.
9. Debugging Production API Issues from Frontend
Frontend developers often blame backend, but senior developers verify first.
What they check
Angular HttpClient example:
this.http.post('/api/orders', payload).pipe(
catchError(error => {
this.logger.error('API error', error);
return throwError(() => error);
})
);
Sometimes the bug is not the API, but the frontend assumption about the API.
10. Configuration Issues: The Silent Killers
Many production bugs are configuration issues.
Examples
Angular uses environment.ts files. A small mistake here can break everything.
Senior developers always:
Diff production config vs staging
Verify build pipeline values
Double-check environment replacements
11. Debugging Angular Change Detection Issues
Change detection bugs appear more often in production because of optimisations.
Common issues:
UI not updating
Async data not reflected
OnPush misuse
Example fix:
constructor(private cdr: ChangeDetectorRef) {}
updateData() {
this.data = newData;
this.cdr.markForCheck();
}
Senior developers understand Angular’s internals enough to recognise these patterns.
12. Memory Leaks and Performance Issues
Production performance bugs are subtle.
Signs:
Common Angular causes:
Unsubscribed observables
Global event listeners
Large component trees
Best practice:
private destroy$ = new Subject<void>();
ngOnInit() {
this.service.data$
.pipe(takeUntil(this.destroy$))
.subscribe();
}
ngOnDestroy() {
this.destroy$.next();
this.destroy$.complete();
}
Senior developers proactively look for memory patterns, not just errors.
13. Feature Flags and Controlled Fixes
Never deploy risky fixes directly to all users.
Senior teams:
Angular integrates easily with feature flag services or backend-driven flags.
14. Rolling Back Safely
Sometimes fixing is riskier than rolling back.
Senior developers:
Know how to rollback fast
Keep rollback scripts ready
Avoid database changes in hotfixes
Frontend rollbacks are simpler, but still require cache invalidation awareness.
15. Post-Incident Analysis: Where Seniors Add Value
Fixing the bug is only 50% of the job.
Post-incident questions:
Why did this reach production?
Why wasn’t it caught earlier?
What monitoring was missing?
What test should be added?
Actions:
Add regression tests
Improve logging
Update runbooks
Improve CI checks
This is how teams mature.
16. Preventing Future Production Issues
Senior developers invest in prevention.
Key practices:
Angular helps with:
TypeScript
Strong module boundaries
Dependency injection
Structured architecture
But discipline matters more than tools.
17. Mental Model of a Senior Debugger
Senior developers:
They debug systems, not just code.
Final Thoughts
Production debugging is a skill built through experience. It is less about clever tricks and more about calm thinking, systematic investigation, and responsibility.
Angular applications in production are complex systems involving browsers, networks, APIs, builds, and users. Debugging them requires understanding all these layers.
The difference between a junior and senior developer is not how fast they write code, but how safely they handle failures.
If you can debug production issues confidently, you are already operating at a senior level.