Version scope
This article targets Umbraco 8, which uses ASP.NET Web API on .NET Framework. Current Umbraco versions use a different ASP.NET Core request pipeline and should not use this implementation.
Benefits of Action Filter Logging in Umbraco
Action filters are useful when you need logging behavior around a defined set of Umbraco Web API actions without repeating the same exception-checking code inside every endpoint.
Simple integration: keep cross-cutting logging outside controller actions.
Granular control: apply the attribute to an entire controller or only to selected actions.
Consistent context: centralize the message and exception logging behavior for the endpoints where you need it.
Important
an asynchronous filter method does not make logging automatically non-blocking. The actual I/O behavior depends on the configured logging sinks. Use the filter primarily for separation of concerns and consistent exception capture, not as a performance optimization.
Step 1: Create the Custom Logging Filter
Create UmbracoCustomLoggingAttribute and inherit from Web API's ActionFilterAttribute. The HttpActionExecutedContext passed to OnActionExecutedAsync exposes the exception raised while executing the action.
public sealed class UmbracoCustomLoggingAttribute : ActionFilterAttribute
{
public override Task OnActionExecutedAsync(HttpActionExecutedContext actionExecutedContext, CancellationToken cancellationToken)
{
if (actionExecutedContext.Exception != null)
{
Current.Logger.Error<UmbracoCustomLoggingAttribute>(actionExecutedContext.Exception, "An unexpected error occurred while executing an Umbraco API action.");
}
return base.OnActionExecutedAsync(actionExecutedContext, cancellationToken);
}
}The filter checks whether the action completed with an exception and, when it did, writes the exception through Umbraco's logger.
Historical API note
Current.Logger is an Umbraco 8-era API. It is appropriate for this legacy example, but it is not a pattern to copy into modern Umbraco / ASP.NET Core code.
Step 2: Apply the Filter
Once the attribute exists, apply it where the additional exception logging is required. Decorating the controller applies the filter to all of its actions:
[UmbracoCustomLogging]
public class TestUmbracoApiController : UmbracoApiController
{
public IHttpActionResult EndpointA(string id)
{
return Json("Hello from Endpoint A");
}
public IHttpActionResult EndpointB(string id)
{
return Json("Hello from Endpoint B");
}
}If only one endpoint needs this behavior, put [UmbracoCustomLogging] directly on that action instead. This selective approach is useful when the filter exists to add diagnostics to a specific API surface.
Step 3: Configure Logging Carefully
Umbraco 8 uses Serilog. The original implementation paired the filter with a global minimum level of Error. That can reduce log volume, but it can also hide useful Warning and Information events from the rest of the application.
For that reason, do not set the entire application to Error merely because this filter logs exceptions at error level. Choose the global minimum level according to your operational requirements. For example:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<!-- Valid values include Verbose, Debug, Information, Warning, Error and Fatal -->
<add key="serilog:minimum-level" value="Information" />
</appSettings>
</configuration>Information is only an example, not a universal production recommendation. The right level depends on your environment, sinks, retention policy, diagnostics requirements, and log volume.
Production recommendation
control noisy categories or sinks more narrowly when possible instead of suppressing every event below Error. Useful warnings often provide the context that explains why an error occurred.
Production Considerations
Avoid sensitive data: do not add passwords, tokens, secrets, or unnecessary personal data to exception messages or custom properties.
Watch for duplicate exception logging: Umbraco or another global error-handling layer may already log an unhandled exception. Verify the resulting logs before applying this filter globally.
Do not swallow the exception: this filter observes and logs it; it does not mark the exception as handled or replace your API error-response strategy.
Prefer useful context over volume: request or correlation identifiers can be more valuable than repeatedly logging the same generic message at multiple layers.
Official References
HTTP Message Handlers in ASP.NET Web API — Microsoft documentation for cross-cutting processing in the classic Web API pipeline.
Exception Handling in ASP.NET Web API — Microsoft documentation covering exception filters and other Web API exception-handling mechanisms.
Serilog Configuration Basics — reference for minimum levels and logging configuration.
Conclusion
A custom action filter is a compact way to add targeted exception logging to Umbraco 8 Web API controllers. Create the attribute, inspect HttpActionExecutedContext.Exception, log through Umbraco's logger, and apply the attribute only where the extra diagnostic layer is useful.
The most important production detail is not to confuse exception-level logging with a requirement to set the entire application minimum level to Error. Preserve enough surrounding diagnostic information to investigate failures effectively.
