Exceptionless: self-hosted error reporting for .NET and JavaScript apps

The problem Exceptionless solves for .NET teams

Unhandled exceptions in a .NET service usually surface in three places: a log file nobody reads, an APM dashboard that samples them away, or a support ticket written by a user. Exceptionless targets the gap between those. The README describes it as real-time error reporting for JavaScript, Node, .NET Core, ASP.NET, Web API, WebForms, WPF, Console and MVC apps, with the gathered information organized into what it calls simple actionable data.

The audience is narrow and specific. Teams already running ASP.NET or .NET Core services, plus a JavaScript or Node frontend, get the most from it, because the same server accepts events from both. Teams that want to keep error data inside their own network have a reason to look here rather than at a hosted service. The repository ships a k8s/ directory and a docker/ directory alongside samples/, so the project clearly expects to be deployed by the operator, not only consumed as an API.

How events move through the Exceptionless stack

Exceptionless is a server, not a library. Clients send events to the web API, which is the Exceptionless.Web project; the Dockerfile builds it separately from Exceptionless.Job, a second process that runs background work. That split is visible in the image targets: api-publish publishes Exceptionless.Web with /p:SkipSpaPublish=true, and job-publish publishes Exceptionless.Job. They become two containers, api and job, each exposing port 8080 and starting with dotnet Exceptionless.Web.dll or dotnet Exceptionless.Job.dll.

Storage and messaging sit outside the .NET code. The repository topics name Elasticsearch and Redis, and the self-hosting documentation is where the README points for anything beyond the test container. So the data flow is: client library posts an event, the API process writes it to Elasticsearch and uses Redis for the coordination the job process also needs, and the job process handles the work that should not block a request. The UI reads back from the same API.

The frontend is split, and the README is unusually direct about it. The legacy Angular UI in src/Exceptionless.Web/ClientApp.angular is still the main site UI. The Svelte 5 UI in src/Exceptionless.Web/ClientApp is still under development. If you self-host, you are running the Angular app unless you choose otherwise, and that is the part of the codebase with the longer history.

Installing Exceptionless with Docker and creating the first account

The README gives a single command for a local instance. It maps container port 8080 to host port 7110 and pulls the latest image:

docker run --rm -it -p 7110:8080 exceptionless/exceptionless:latest

After it starts, open http://localhost:7110 in a browser. You should see the Exceptionless sign-up screen. Create an account there, and note the README's statement that the first account in the system is automatically an admin. That account is the one you will use to create an organization, a project, and an API key for your application.

The README is explicit that this container is not a production setup: it says the instance is only suitable for testing purposes since it will not persist data. The --rm flag in the command above reinforces that, since the container is deleted on exit.

For a configuration that survives a restart, the repository carries samples/docker-compose.yml and samples/docker-compose.all-in-one.yml, and the README points to the self-hosting documentation at exceptionless.com/docs/self-hosting/ for more complete setups. Those files are the ones to read before planning a deployment, because they show which supporting services the compose setup expects.

Building from source is a separate path. The contributing document lists Docker, .NET 10.0 and Node 24+ as prerequisites, and the entry points are the Aspire launch configuration in Visual Studio Code, Exceptionless.AppHost as the startup project in Visual Studio, or aspire run from the repo root. In Development mode the README states that a global administrator user [email protected] with password tester is created automatically, which saves you the sign-up step when you are working on the code itself.

Where Exceptionless is the wrong tool

The all-in-one container is the clearest limit. It is documented as non-persistent, so anything you send to it disappears when the container does. Anyone who wants a small always-on error inbox for a side project has to move to the compose or Kubernetes path, and that path brings Elasticsearch and Redis with it. The operational surface is therefore much larger than the one-line install suggests.

There is also a real cost to the two-process design. Exceptionless.Web and Exceptionless.Job are separate images with separate publish steps, and both need the same backing services. A team without existing Elasticsearch or Redis experience is signing up for two more systems to run, monitor and upgrade, in exchange for owning the error data.

The frontend situation is a second limitation worth naming. The README states that the Svelte 5 UI is still under development while the Angular UI remains the main site UI. That means the interface most users will see is the older one, and anyone hoping to contribute UI work needs to decide which of the two apps they are targeting before writing code.

Finally, the documentation surface is thin in this repository. The README defers to exceptionless.com/docs/ for usage and to the self-hosting page for deployment. If your evaluation depends on reading configuration details from the repository alone, you will not find them here.

Exceptionless against Sentry and other hosted error trackers

The obvious comparison is Sentry, and the difference is not features so much as who runs the database. Sentry is offered as a hosted service and as a self-hosted deployment; Exceptionless is built around the assumption that you host it, with a paid hosted option at exceptionless.com as the alternative. The README frames the hosted service as a way to support the project, which tells you where the project's center of gravity sits.

In practice the choice comes down to what you are willing to operate. Sentry's self-hosted path is a large compose stack of its own; Exceptionless asks for Elasticsearch and Redis and two .NET containers. Neither is a small footprint. The tiebreaker for a .NET shop is usually the client libraries and the shape of the grouping, and Exceptionless is written in C# with ASP.NET and .NET Core as first-class targets, which is why the topics list reads the way it does.

A second, less direct alternative is doing nothing new: structured logs in Elasticsearch with a dashboard on top. That gets you the raw events without a grouping engine, an alerting model, or a second web application to keep patched. If your team already queries logs directly, the value Exceptionless adds is the grouping and the workflow around it, not the storage.

Maintenance, licensing and upgrade cost

Exceptionless is licensed under Apache-2.0, which permits commercial use and modification, and the LICENSE.txt file sits at the repository root. The practical implication for a self-hoster is that running a modified build internally is allowed, but the licence text itself is what governs, and this is not legal advice. If you plan to redistribute a modified version, read LICENSE.txt rather than relying on a summary.

The project is not archived, and the last push to main was on 2026-09-28. Recent releases include v8.9.0 on 2026-09-03, v8.8.4 on 2026-08-26 and v8.8.3 on 2026-08-25, so version numbers move on a short cadence. That matters for upgrade planning: the Dockerfile pins mcr.microsoft.com/dotnet/sdk:10.0.401 for the build stage and mcr.microsoft.com/dotnet/aspnet:10.0.12 for the runtime, which means a .NET major version sits underneath the application and will need attention on its own schedule.

The upgrade cost that is easy to miss is the data layer. Elasticsearch and Redis versions are not pinned in the README, and the self-hosting documentation is the place the project sends you for that. Before adopting, check which Elasticsearch version the compose samples expect and whether your existing cluster matches, because that determines whether you are adding a service or replacing one.

Editorial conclusion

Adopt Exceptionless if you already run .NET services and want exception data on your own infrastructure rather than in a vendor account. Do not adopt it if you need a single container to hold production data, because the README states the Docker quick start does not persist anything. Before committing, read the self-hosting documentation, check the samples/docker-compose.yml file against your own Elasticsearch and Redis deployment, and decide which of the two frontends you will actually maintain, since the Svelte 5 UI in src/Exceptionless.Web/ClientApp is described as still under development while the Angular app remains the main site UI.

Frequently asked questions

Official sources

1. exceptionless/Exceptionless on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases