How do you implement global exception handling and structured logging in a production ASP.NET Core API?

Say it out loud, then check

One failing request, in the logs

What Application Insights holds a minute after the error, cut down to fit a phone. union traces, exceptions reads both tables at once: log lines land in traces, logged exceptions in exceptions. Levels are numbers: Information 1, Warning 2, Error 3.

The story

1. Before

   UDC Finance's customer API has about thirty actions (controller methods that each answer one kind of request). In the first version, each one wrapped its work in its own try/catch (a block that tries the work and catches an exception, the error object thrown when something fails): it wrote the exception to the log and returned a 500 with some JSON. Every action did it slightly differently.

   Statementtry/catch: own JSON

   Change daytry/catch: message

   PayOffno try/catch

   1/4Before: every action catches its own exceptions and answers in its own shape.One sends the exception message to the customer. One has no catch: an empty 500 with no body.Fix: one global handler at the start of the pipeline. The actions drop their try/catch.Every unhandled error is logged once and answered the same safe way, with an id.

   BackPlayNext
2. Why it had to change

   Copied error handling drifts. One action returned the raw exception message to customers; another forgot the catch, so the customer got an empty 500 with nothing to quote to support. The logs were plain sentences, so support couldn't find the lines for one customer's failed request among thousands.

3. How it works now

   ASP.NET Core gives one place for this. A middleware is a step every request passes through, in order; the whole list of steps is the pipeline. The middleware UseExceptionHandler, near the start of the pipeline, catches any exception thrown after it and hands it to your exception handler class. That class logs the full error and answers with a safe ProblemDetails body (the standard JSON error shape). For the logs, structured logging keeps every value as a searchable field, and a correlation id on every line ties one request's lines together. The main diagram follows one failing request through both.

4. What we gained

   Actions only do their own work, every error answers the same safe way, and support goes from the id on the customer's screen to the exact log lines in one search. The rest of the card shows the handler chain, what never to log, and the week UDC's errors showed customers a server name.

In the lending API

The global handler: the one place an unhandled exception becomes a log line and a safe 500.

Only the key lines are shown; Deep walks the whole file.

The code, file by file

The UDC customer API: start-up, the correlation id, a controller and the global handler. Tap Next to walk one failing request.

What they ask next

The follow-ups interviews really ask. Answer out loud, then tap to check.

• ReportedHow would you create a global exception handler?

  In .NET 8 and later: a class that implements IExceptionHandler, registered with AddExceptionHandler<T>(), plus AddProblemDetails(), and app.UseExceptionHandler() near the start of Program.cs. Its TryHandleAsync logs the exception and writes a 500 ProblemDetails. Before .NET 8 the same idea was a custom middleware with try { await next(context); } catch (Exception ex) { ... }, or UseExceptionHandler with an error path.

  Next questions, in Deep →Walk the main code →Infosys: global exception handler
• ReportedHow do you handle production errors?

  In the code: one global handler that logs the full error and returns a safe 500 with a correlation id. Around it: Application Insights collects the logs and requests; an alert fires on the rate of 500s, not on single lines; the on-call person takes the correlation id or time from the ticket, finds the request in one query, and follows the runbook. After a fix, a regression test and a postmortem. The incident in Deep walks one end to end.

  Next questions, in Deep →Walk the incident →Infosys: handling production errors
• ReportedHow do you implement error logging in .NET Core?

  Through ILogger<T>, which DI gives every class. Providers decide where lines go: the console locally, Application Insights in Azure. Levels are set per category in appsettings.json. Errors are logged with the exception object, LogError(exception, "..."), so the stack trace is kept.

  "Logging": {
    "LogLevel": {
    "Default": "Information",
    "Microsoft.AspNetCore": "Warning"
    }
  }

  Next questions, in Deep →Corporate Infotech: error logging in .NET Core

Follow-up tree

Answer, then open the next level. That is the order an interviewer digs in.

Reporteda candidate was asked Intervieweran interviewer asks it

• ReportedHow would you create a global exception handler?

  In .NET 8 and later: a class that implements IExceptionHandler, registered with AddExceptionHandler<T>(), plus AddProblemDetails(), and app.UseExceptionHandler() near the start of Program.cs. Its TryHandleAsync logs the exception and writes a 500 ProblemDetails. Before .NET 8 the same idea was a custom middleware with try { await next(context); } catch (Exception ex) { ... }, or UseExceptionHandler with an error path.

  Walk the main code →Infosys: global exception handler
• ReportedHow do you handle production errors?

  In the code: one global handler that logs the full error and returns a safe 500 with a correlation id. Around it: Application Insights collects the logs and requests; an alert fires on the rate of 500s, not on single lines; the on-call person takes the correlation id or time from the ticket, finds the request in one query, and follows the runbook. After a fix, a regression test and a postmortem. The incident in Deep walks one end to end.

  Walk the incident →Infosys: handling production errors
• ReportedHow do you implement error logging in .NET Core?

  Through ILogger<T>, which DI gives every class. Providers decide where lines go: the console locally, Application Insights in Azure. Levels are set per category in appsettings.json. Errors are logged with the exception object, LogError(exception, "..."), so the stack trace is kept.

  "Logging": {
    "LogLevel": {
    "Default": "Information",
    "Microsoft.AspNetCore": "Warning"
    }
  }

  Corporate Infotech: error logging in .NET Core
• Exception middleware, exception filter or try/catch: which and when?

  The global safety net is middleware: it sees everything, including other middleware and writing the response. An exception filter only sees MVC (the action, binding, action filters), so I use one at most to map a domain exception for controllers (the filters card). Try/catch belongs where the code can actually do something: retry, fall back, or add context and rethrow.

• What happens if the exception is thrown after the response has started?

  Too late to change it. The exception handler logs a warning, "The response has already started, the error handler will not be executed", and the connection is cut; in our test on .NET 10 the client got 200 and half a JSON body. It happens with streaming or large responses. Build the whole result before writing, or accept that the client sees a broken response.

• Should every layer catch, log and rethrow?

  No. The same error ends up in the logs three times, and the stack trace gets harder to read. Log once, at the boundary: the global handler. A layer catches only to add context, throw new FisTimeoutException("...", ex) with the original as the inner exception, or to recover. On .NET 10, when your IExceptionHandler returns true, the middleware doesn't write its own error line as well. Earlier versions also logged it, so check your version's docs and filter the duplicate if you see two.

• What must never go into logs?

  Passwords, tokens, API keys, full card or bank account numbers, and personal data you don't need, like names, addresses or tax numbers. Logs are copied widely and kept long. Log ids instead (contract id, customer id), and check what a whole object would log before passing it to a template.

• Log levels: what goes where?

  Error: something failed that someone should look at. Warning: unexpected but handled, like a rejected submission. Information: the main steps of a request. Debug and Trace: detail for local work, off in production. Each category (usually a class name) can have its own level in appsettings, so Microsoft's chatty lines stay at Warning.

Production bugs, and how to tell them

Each one: what you see, why, the fix in code, and the line to say.

• Every 500 lost its correlation id

  HTTP/1.1 500 Internal Server Error
  (no X-Correlation-ID header)
  
  union traces, exceptions
  | where customDimensions.CorrelationId == "c-81f2"
  → 1 row: "Loading statement for 7"
     (the error line is missing)

  Cause

  Two small mistakes. The correlation middleware was registered after UseExceptionHandler, so by the time the handler logged the error, the scope with the id had already closed: the error line had no CorrelationId. And the middleware set the response header straight away; on an error, the exception handler clears the response, headers included, before it writes the 500, so the header was gone. (The query uses union traces, exceptions because Application Insights keeps log lines in traces and logged exceptions in exceptions.)

  Fix

  Register the correlation middleware before UseExceptionHandler, and set the header inside Response.OnStarting, which runs just before the response is sent, after the handler has cleared it. Both checked on .NET 10: header and error line both carry c-81f2.

  BeforeBeforeAfterAfter

  Diagram · step 1Before: exception handler first, correlation second. It sets the header and opens its scope.Show diagram

  Handler1st

  Corr. ID2nd

  Code

  Logs

  next

  header + scope

  1app.UseExceptionHandler();2app.UseMiddleware<CorrelationIdMiddleware>();

  Before · Program.cs · line 1 · 1 of 2First, so it sits outside the correlation middleware.

  BackNext line

  Say it

  The correlation middleware must wrap the exception handler, or the error is logged outside its scope, and the header must be set in OnStarting, because the exception handler clears the response before writing the 500.

• Logs couldn't be searched by contract

  traces
  | where customDimensions.ContractId == "7"
  → 0 rows
  (but "Loading statement for 7" is right there in message)

  Cause

  A developer wrote the log call with string interpolation, $"Loading statement for {id}". C# builds the finished sentence before ILogger sees it, so the template is different for every contract and there is no ContractId field: only text. Checked on .NET 10: the interpolated line has no ContractId in its fields; the template version has it.

  Fix

  Use a message template with a named hole and pass the value separately. A built-in code analysis rule flags a log message that isn't a fixed template; we turned it into a build warning.

  BeforeAfter

  1_log.LogInformation(2 $"Loading statement for {id}");

  Before · StatementsController.cs · line 2 · 1 of 1$"..." builds the text first. The logger gets "Loading statement for 7" and nothing else.

  BackNext file

  Say it

  With interpolation the logger only receives finished text, so the value isn't a field. A message template keeps the text and stores ContractId as its own searchable field.

Traps

• Don't sayReturn exception.Message so the client knows what went wrong.SayReturn a safe title and the correlation id. The message stays in the logs: it can hold server names, SQL or customer data.
• Don't sayPut a try/catch in every action to be safe.SayOne global handler. Try/catch only where the code can recover or add context.
• Don't sayLog with $"Loaded {id}"; it's the same text.SaySame text, but no field. A template keeps {ContractId} searchable.
• Don't sayAn exception filter is enough for global error handling.SayIt misses middleware and response writing. The safety net is UseExceptionHandler.

Traps

What should you say instead? Tap to check.

• Don't sayReturn exception.Message so the client knows what went wrong.

  Say instead

  Return a safe title and the correlation id. The message stays in the logs: it can hold server names, SQL or customer data.

• Don't sayPut a try/catch in every action to be safe.

  Say instead

  One global handler. Try/catch only where the code can recover or add context.

• Don't sayLog with $"Loaded {id}"; it's the same text.

  Say instead

  Same text, but no field. A template keeps {ContractId} searchable.

• Don't sayAn exception filter is enough for global error handling.

  Say instead

  It misses middleware and response writing. The safety net is UseExceptionHandler.