Each service logs to elmah.io with the same correlation ID, so the API call, the queue message and the worker crash show up as one story.
The term 'Microservices' covers an architectural style of building applications that has gained a lot of focus in recent years. A lot of the thoughts behind microservices were born from experiences with Service Oriented Architecture (SOA), which was the next big thing a decade ago.
The idea with microservices is to split an application into multiple independent deployable services, each with a single concern. Rather than building, maintaining and deploying an application as a monolith, microservices with a predefined interface can evolve or be easily replaced, without affecting the remaining parts of the application. A microservice can communicate with other microservices over the network. Communication is often based on REST and/or through a queue/service bus.
A microservice architecture introduces both advantages and disadvantages. Some of the advantages of using microservices are:
Let every service log to the same elmah.io log and set the Application property on each message to the name of the service. You get an overview of all your microservices in the same dashboard, and you can filter down to a single service when you need to.
You can create as many logs as you need, for example to give a team its own notifications and access control. Correlation works within a log, so services that need to be followed together should share one.
Install the Elmah.Io.Client.Extensions.Correlation package and call WithCorrelationIdFromActivity. Every message then picks up the trace ID of the current activity, and messages from different services that handled the same request share an ID you can filter on.
The ASP.NET Core integration also reads the traceparent header of incoming requests, so a request that travels through your services keeps its trace ID. The API call, the queue message and the worker crash end up as one story.
Notifications go out through email, Slack, Microsoft Teams and more. Want to send Slack notifications to the core team and mails to third-party vendors? Set up rules per log, and the right people hear about the right errors.
Pay the same low price, no matter how many servers and CPUs you use.
A worker that stops consuming messages does not log an error. Heartbeats notify you when a background service fails to check in, and the documentation shows how to add them to .NET worker services. Uptime monitoring covers the services that listen on HTTP.
Connect Claude Code, Cursor, VS Code or Visual Studio to the elmah.io MCP server. Each message the agent reads includes the name of the service and the correlation ID, so it can follow one request from service to service.
In Claude Code, add the server with one command:
claude mcp add --transport http --client-id claudecode elmahio https://mcp.elmah.io/mcpThe MCP server is included on every plan and is currently in beta. Set up the MCP server.
elmah.io itself runs as dozens of .NET services and Azure Functions, and all of them log to elmah.io. When something fails in our own system, we use the same notifications, correlation and heartbeats that we describe on this page.
For correlation, yes. Correlation currently works within a single log, so use the same log ID everywhere and set the application name on each service to tell the services apart.
Through the CorrelationId property on each message. The correlation package sets it from the current activity, and you can set it yourself from a header or a message ID if you use another scheme.
Yes. You can create as many logs as you need. Messages in different logs are not correlated with each other, so choose this when separate access and notifications matter more than following requests.
No. You pay the same no matter how many servers and CPUs you use. The plan decides how many messages you can log.
Yes. Connect the elmah.io MCP server to Claude Code, Cursor, VS Code or Visual Studio. It is included on every plan and is currently in beta.