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.
Architecture fit: Stable v1.0.0 is a typed Laravel client for GlitchTip’s management API, not an error-ingestion SDK. It fits Laravel back-office automation, tenant provisioning, monitor/heartbeat management, project/key administration, and usage reporting. Readonly DTOs, cursor pagination with lazy(), and scoped clients via using() / usingSession() align well with Laravel service-container and multi-tenant patterns. The session client is narrowly suited to same-origin browser-served apps; backend jobs should use token-based per-account clients.
Integration feasibility: Low initial integration cost via composer require wojt-janowski/laravel-glitchtip. The OpenAPI coverage test is a strong signal that endpoint coverage is intentional rather than ad hoc. Guzzle 8 support aligns with current Laravel 13 installs. The opt-in live integration suite against self-hosted GlitchTip 6.2.6 improves confidence in create/update/delete flows, though it is not part of default CI unless configured.
Technical risk: Primary risk is behavioral coupling to GlitchTip versions and self-hosted configuration. The release fixes several upstream quirks—snake_case is_up, missing fields causing 500s, stats_v2 daily bucket behavior, and updateKey() being a no-op on GlitchTip 6.2—which shows the package absorbs API inconsistencies but also means target-instance validation matters. Session auth depends on cookies, CSRF tokens, and origin/referer headers, so it should be treated as security-sensitive. Retrying only idempotent requests is the right default, but callers must still avoid externally retrying POSTs.
Key questions: What Laravel/PHP version matrix is officially supported? What token scopes and permissions are required per operation? What are GlitchTip’s rate limits and expected pagination sizes? How are API errors mapped to exceptions? Which GlitchTip versions are supported beyond the tested 6.2.6? What is the deprecation/versioning policy for the package? What guidance exists for securely storing and rotating session cookies/CSRF tokens? Does the live integration suite run in the maintainer’s CI, and with what coverage?
Stack fit: Best fit is a Laravel application already using GlitchTip as its error-tracking backend and needing management-plane automation. It complements, rather than replaces, an error-reporting SDK. Typical uses include provisioning organizations/projects, managing keys and monitors, sending heartbeats, and pulling usage/stats for internal dashboards. The package should be configured through Laravel config/services and injected into jobs, commands, or admin services.
Migration path: For teams using raw HTTP calls or custom GlitchTip wrappers, migrate incrementally: replace read-only endpoints first, validate DTO shapes and pagination, then migrate write operations with explicit rollback/cleanup behavior. This is not a migration path for error ingestion; existing Sentry/GlitchTip SDK usage remains separate. Because there is no prior assessment, treat v1.0.0 as the initial baseline and pin it deliberately.
Compatibility: Confirm PHP, Laravel, and Guzzle versions before rollout; Guzzle 8 support is relevant for Laravel 13. Validate against the exact GlitchTip version in each environment, especially self-hosted instances. Billing behavior differs: usage, daily usage, and overage status work on self-hosted GlitchTip from 6.1.3, 6.1.4, and 6.2.1 respectively, while Stripe plan/subscription/checkout/portal calls require Stripe billing. Session-based clients only make sense when the Laravel app is served from the GlitchTip instance’s origin.
Sequencing: Install in non-production, configure a token-based account client, and smoke-test read endpoints and lazy() pagination. Then test write operations in a disposable organization, using the opt-in live suite where possible. Roll out per-tenant clients via using() for multi-account support. Add usingSession() only if same-origin browser integration is explicitly required and security review is complete. Finally, enable in production with version pinning, monitored failures, and documented fallback procedures.
Maintenance: Pin the package and track GlitchTip releases plus OpenAPI changes. The coverage test reduces hidden-endpoint risk, but upstream behavioral changes can still surface through field quirks, validation rules, and version-specific no-ops. Budget for periodic compatibility checks against self-hosted and hosted GlitchTip variants.
Support: Support load will center on credential configuration, token scopes, organization slugs, auth-mode selection, and version-specific behavior. Document when to use using() versus usingSession(), how CSRF/session expiry appears, and which billing endpoints are unavailable without Stripe. The project should also document cleanup expectations for integration tests that create and delete real resources.
Scaling: Cursor pagination and lazy() help control memory for large result sets. API rate limits, network latency, and GlitchTip server capacity will dominate scaling more than PHP overhead. Queue bulk provisioning and stats collection, avoid synchronous fan-out across many accounts, and use per-account clients to isolate tenants. Retries should remain limited to idempotent operations.
Failure modes: Expect auth failures from expired tokens or session cookies, CSRF/origin problems in session mode, 404s for unsupported billing calls on self-hosted instances, and 500s from upstream validation edge cases—several of which this release fixes. projects()->updateKey() is a documented no-op on GlitchTip 6.2, so workflows must not depend on key mutation there. Daily stats are aggregated from hourly buckets, which may affect freshness and query cost. Non-idempotent POSTs must not be retried blindly by surrounding infrastructure.
Ramp-up: Moderate for Laravel developers; low once credentials, organization context, and pagination patterns are understood. The main learning curve is GlitchTip API semantics and auth-mode boundaries, not Laravel integration. The opt-in live suite is valuable but adds setup cost for secrets and disposable test resources, so teams should decide early whether it runs locally, in CI, or only during upgrades.
How can I help you explore Laravel packages today?