wojt-janowski/laravel-glitchtip
A Laravel integration for GlitchTip, the open-source, Sentry-compatible error tracking service. Automatically captures exceptions and reports them to your GlitchTip instance, so you can monitor application errors without relying on a hosted third-party service.
Install the package with Composer:
composer require wojt-janowski/laravel-glitchtip
Start by reading the package README and the resource clients (projects(), issues(), monitors(), users(), socialApps(), stats(), billing, etc.). The v1.0.0 guarantee is important: every operation in GlitchTip’s OpenAPI spec is either implemented or explicitly excluded with a stated reason, and a test enforces that coverage. If a method appears to be missing, check the package’s exclusion list before assuming it is a bug.
Configure the GlitchTip instance URL and API credentials as documented by the package, then validate with a read-only call. A good first use case is listing projects or issues for an organization so you can confirm authentication, organization scoping, and DTO shape before wiring up writes.
For multi-account usage, create clients with GlitchTip::using(...) rather than changing global state. For browser-session-based access, use:
GlitchTip::usingSession($url, $sessionId, $csrfToken, $organization);
Use the default client for the application’s primary GlitchTip account, using() for per-tenant or per-account clients, and usingSession() only where the app is served from the GlitchTip instance’s origin and can supply Django-compatible session and CSRF values.
Use the resource clients as the main integration surface. Methods return typed, readonly data objects, so consume properties directly instead of treating responses as loose arrays. This makes jobs, admin tools, and dashboards easier to refactor because API field changes surface as type errors rather than silent array misses.
For list operations, prefer cursor pagination with lazy() when syncing projects, issues, users, or other large collections. Process items as a stream rather than loading everything into memory. This is especially useful in scheduled jobs that reconcile GlitchTip data with local models.
For multi-tenant applications, resolve the correct GlitchTip client per account and pass it into the service or job that performs the work. Avoid storing one global client if different teams, organizations, or environments use different GlitchTip credentials.
Use usingSession() for frontend-adjacent integrations where the user is already signed in to GlitchTip. It sends the sessionid and csrftoken cookies plus the X-CSRFToken, Origin, and Referer headers Django’s CSRF checks need. Keep this path separate from backend API-token clients; it is not a replacement for long-lived server credentials.
Write operations should be modeled as explicit workflows: create, verify, update, delete. The package retries idempotent requests only, so a POST is never sent twice by the client. If your own job or queue retries a create operation, add application-level idempotency checks to avoid duplicate resources.
For monitor maintenance, use the typed monitor methods and account for GlitchTip’s quirks. monitors()->heartbeat() now reports the correct up/down state, and monitors()->update() handles monitors without a URL by sending an empty string. That makes heartbeat-style monitors safe to update, but still pass explicit values when changing configuration.
For user and social app administration, the v1.0.0 fixes reduce surprising 500s: users()->update() preserves the current name when no name is supplied, and socialApps()->update() keeps the current issuer URL when serverUrl is omitted. Prefer sending complete update payloads anyway, especially in automated provisioning.
For stats, use stats()->series(interval: StatsInterval::Day) for daily reporting. GlitchTip 6.2’s stats_v2 returns only the first hour of each day, so the package now aggregates hourly buckets into daily totals. If you need finer control, request hourly data and aggregate yourself.
For billing-related features, treat self-hosted GlitchTip differently from Stripe-backed billing. Usage, daily usage, and overage status work on self-hosted GlitchTip from 6.1.3, 6.1.4, and 6.2.1 respectively. Only the Stripe plan, subscription, checkout, and portal calls require Stripe billing.
For testing, follow the package’s opt-in live integration suite pattern: run create/update/delete scenarios against a disposable GlitchTip organization and clean up afterward. Keep those tests out of the default unit suite, and mock HTTP interactions for normal application tests.
projects()->updateKey() is a documented no-op on GlitchTip 6.2: it returns the key unchanged. Do not build key-rotation workflows around it without verifying against your GlitchTip version.monitors()->heartbeat() previously reported every monitor as down because the endpoint answers in snake_case (is_up). v1.0.0 fixes this, but older package versions or custom wrappers may still have the bug.monitors()->update() now sends a missing URL as an empty string. If you are validating monitor payloads locally, allow empty URLs for heartbeat-style monitors.users()->update() now sends the current name back when no name is provided. This avoids a GlitchTip 500, but it also means an omitted name is not the same as clearing the name.socialApps()->update() now preserves the existing issuer URL when serverUrl is omitted. Pass serverUrl explicitly if you intend to change it.lazy() for cursor pagination in sync jobs. Avoid calling “list all” helpers in memory-constrained workers.usingSession() depends on browser cookies and CSRF headers. It is suitable for apps served from the GlitchTip instance’s origin, not for queue workers, CLI commands, or cross-origin frontends.How can I help you explore Laravel packages today?