Add GlitchTip hosting and .NET client integrations

[sliekens]

Related to an existing integration?

No. This proposes GlitchTip hosting and .NET client integrations. Draft implementation: #1594.

Overview

What is GlitchTip?

GlitchTip is an open-source application monitoring service that you can host yourself. It combines error tracking, searchable logs, performance monitoring, and uptime checks. Applications report through Sentry-compatible SDKs.

GlitchTip groups errors into issues that teams can investigate and resolve. It provides a shared place to follow application problems across releases and deployments. Its feature guides cover these workflows.

This proposal connects that service to the Aspire application model. Aspire supplies project identity, reporting configuration, uptime declarations, and release artifacts. Applications still own their instrumentation and builds.

Capability map

This table separates GlitchTip capabilities from the proposed Toolkit integration's responsibilities.

Capability	GlitchTip provides	Proposed integration
Errors and issues	Error collection, grouping, stack traces, and issue triage	Configure the Sentry SDK through generic .NET and ASP.NET Core client packages. Errors are enabled by default.
Logs	Searchable application logs	Opt-in log reporting through the client integration.
Traces and performance	Transactions, spans, and performance investigation	Opt-in tracing configuration. Applications provide instrumentation. Existing OpenTelemetry exporters remain intact.
Uptime	Scheduled checks and outage alerts	Create and reconcile HTTP monitors from supported Aspire health-check declarations.
Releases	Release context for reported events	Supply release, AppHost environment, and service identity consistently to clients and artifacts.
JavaScript source maps	Resolve minified stack traces to source locations	Upload prepared JavaScript/source-map pairs. The application build generates maps and injects matching debug IDs.
Debug symbols	Process dSYM, PDB, and ELF debug files	Upload registered build outputs. The application build generates the files.
Alerts	Email and other supported notification integrations	Operators configure alert rules and delivery on the shared instance. This proposal does not provision SMTP or notification policies.
MCP	AI-assisted access to issues, logs, performance data, and monitors	Enable the MCP endpoint on the local instance. Operators control MCP on the shared instance.

See the GlitchTip MCP guide and the draft integration README for access and integration details.

How does this relate to the Aspire dashboard?

The tools serve complementary workflows. The Aspire dashboard helps inspect a running application. GlitchTip adds retained issue history, release context, and alerts across deployments.

Concern	Aspire dashboard	GlitchTip in this proposal
Application model	Resource state, endpoints, console output, and lifecycle commands when connected to an AppHost	Receives application reports. Does not control Aspire resources.
Telemetry	OpenTelemetry logs, distributed traces, and metrics	Errors, logs, transactions, and spans through compatible SDKs. This proposal adds no general metrics backend.
History	Bounded, in-memory telemetry for development and short-term investigation	Stored reports and issues, subject to the instance's retention policy.
Operational workflow	Inspect current resource health and request behavior	Triage recurring errors, examine release context, and receive uptime or error alerts.
AI access	Aspire CLI and dashboard MCP support	GlitchTip's own MCP support for its stored monitoring data.

This proposal keeps the existing dashboard and OpenTelemetry configuration available alongside GlitchTip.

Local development and deployment have different owners

One Aspire stack maps to exactly one GlitchTip project. All reporting resources in that stack share the project. Independently managed stacks must use distinct project slugs within a shared organization.

Concern	Local development	Deployment
GlitchTip server	Aspire starts a private instance for the AppHost/worktree.	An existing, externally managed instance must already be available.
Database and server infrastructure	Aspire starts PostgreSQL for that local instance. Redis and Valkey are excluded.	The platform operator owns hosting, databases, storage, networking, upgrades, backups, retention, and email delivery.
Organization and teams	Local setup creates the development organization and initial team.	The operator supplies an existing organization and initial team. Aspire does not create them.
Application project	Aspire creates or resolves the stack's project.	Aspire creates or resolves the stack's project inside the supplied organization.
Project team membership	Local setup assigns the initial team.	Aspire assigns the initial team only when creating the project. Later team assignments remain externally managed.

Deploying the application does not deploy GlitchTip or its database. The published infrastructure excludes the local GlitchTip resources. Stopping or removing the application does not delete the shared project, its events, or its artifacts.

The shared instance aggregates reports from many application deployments. Its capacity and lifecycle belong to the platform, independently of any one application. A private local instance lets developers test the integration without access to that shared infrastructure.

“Externally managed” describes the server, organization, and teams. The application project remains Aspire managed, including an existing project found at the configured identity. There is no externally owned project mode or DSN override.

Usage example

builder.AddDockerComposeEnvironment("compose");

var project = builder.AddParameter("glitchtip-project", "my-stack");
var release = builder.AddParameter("release", "local");
var glitchtip = builder.AddGlitchTip("glitchtip", project, release);

builder.AddProject<Projects.Api>("api")
    .WithGlitchTipHealthCheck("/health", endpointName: "http")
    .WithReference(glitchtip);

The API must expose that endpoint and register its client SDK. A resource reference supplies configuration, not application instrumentation.

AddGlitchTip registers deployment behavior automatically. For a resource named glitchtip, deployment requires these parameters:

Parameter	Required value
glitchtip-url	Base URL of the existing shared instance
glitchtip-organization	Existing organization slug
glitchtip-initial-team	Existing team slug, used only during project creation
glitchtip-api-token	Secret management API token with the required project, key, monitor, and artifact permissions

The management token is not forwarded to reporting services. The AppHost environment supplies the reporting environment, such as aspire deploy --environment production.

Changing the initial-team parameter does not move an existing project. Operators can manage multiple team assignments in GlitchTip without Aspire overwriting them.

Scope and ownership

• Publish: Emit unresolved reporting references without contacting GlitchTip or provisioning shared infrastructure.
• Deploy: Resolve the project and a fresh reporting DSN before preparing application configuration. There is no durable DSN cache.
• Uptime: Reconcile Aspire-managed monitors for the project/environment. The shared server needs a reachable, unauthenticated health URL. Deployment does not probe its availability.
• Artifacts: Upload registered build outputs and check server acceptance. Later processing runs asynchronously. Local artifact uploads are opt-in.
• Failure behavior: Management, required upload, or configuration failures block deployment. Runtime reporting failures do not change application readiness.
• Platform operations: Operators own server health, notification delivery, and alerts for later artifact-processing failures.
• Examples: C# and TypeScript AppHosts demonstrate the public hosting contract.

Docker Compose is the initial target for automatic deployment ordering. Other rollout systems can call the management steps with explicit ordering and monitor URLs.

Applications that cannot accept a GlitchTip dependency during emergency deployment can register the integration and its references conditionally.

Breaking change?

No existing integration API changes are proposed.

Alternatives

• Declare local containers and provision shared-instance projects through application-specific scripts.
• Use the Sentry SDK directly and configure every service separately.
• Deploy a GlitchTip instance with every application deployment. This couples a shared monitoring service to an individual application's lifecycle.

Additional context

The draft targets Aspire 13.5 and GlitchTip 6.2.6. Source-map debug-ID preparation remains a build responsibility. Universal Mach-O files require separate thin debug files.

Help us help you

Yes, I would like to contribute the implementation.