Download the PHP package logtracker/laravel without Composer

LogTracker for Laravel

LogTracker is a local, open-source incident tracer for Laravel. It turns the logger and lifecycle signals Laravel already emits into a Rollbar-style Items inbox and execution-story detail page.

No Rollbar package is required. No collector, account, API key, subscription, or hosted service is involved. By default, no telemetry leaves the application.

Status: 1.0.0 release-ready. The package includes the local recorder, complete dashboard, privacy defaults, issue workflow, encrypted runtime controls, optional notifications, lifecycle tooling, and the Laravel/database compatibility fixtures described below.

Requirements

• PHP 8.3 or newer
• Laravel 11.31, 12, or 13
• SQLite, MySQL, or PostgreSQL through Laravel's database layer

Laravel 11 remains source-compatible and is covered by the package test matrix. As of July 2026, Composer's security blocking rejects a fresh Laravel 11 dependency solve because of upstream framework advisories. Do not disable security auditing for a production install; prefer Laravel 12 or 13 for new applications. The Laravel 11 CI fixture uses --no-blocking only so those upstream advisories do not hide compatibility regressions in this package.

Install

LogTracker is available on Packagist. Until the first stable tag is published, install the current dev-main build:

Then install and verify the package:

Open /log-tracker.

The installer creates config/log-tracker.php with a unique, immutable installation ID. Do not copy that value between applications. Package migrations are loaded automatically.

Dashboard

The package owns its Blade views and CSS; the host application does not need a frontend build. Desktop and mobile layouts expose six working surfaces:

• Items groups recurring incidents and supports assignment, mute, resolve/reopen, retained occurrence history, activity, stack, context, and execution-story inspection.
• Occurrences lists each retained trigger with Item, execution, environment, duration, and trace links. Search, level, execution-type, environment, time-period, and signed-cursor filters are supported.
• Traces lists retained execution stories with W3C identifiers, status, duration, span count, and occurrence count. Each trace opens to its complete timeline, context, spans, and linked Items.
• Search searches the sanitized Item, occurrence, and execution indexes from any dashboard page.
• Notifications configures and safely tests Laravel mail and HTTPS Slack delivery without rendering a stored webhook back into the browser.
• Configuration manages bounded capture thresholds, trigger levels, privacy-safe affected-user counting, signed queue-context limits, and retention.

Use Laravel's existing logger

Existing application code is enough:

MessageLogged makes that an incident trigger at configured levels. Lower levels become bounded breadcrumbs when an execution is already active. Channels built outside Laravel's log manager may not emit MessageLogged and are therefore outside the automatic guarantee.

Manual capture is available for cases that are not logs:

capture() never reports, throws, swallows, or rethrows an exception. The host application retains control of its exception policy.

Production authorization

Local access is allowed only when both conditions are true:

• APP_ENV=local
• the request comes from 127.0.0.1 or ::1

Every other environment denies access until the application defines both gates. viewLogTracker protects every dashboard read; manageLogTracker protects Item state changes, notification changes/tests, and runtime configuration changes:

Or register one runtime callback in an application service provider:

Run php artisan log-tracker:doctor --production before enabling the dashboard in production. A user who can view but not manage receives an explicitly read-only dashboard; mutation endpoints still enforce the manage ability server-side and use Laravel's CSRF middleware.

What is captured

The native recorder uses Laravel's public surfaces:

Successful roots do not write to the LogTracker database.

Privacy defaults

Every persistence path uses the same recursive sanitizer:

• sensitive keys such as authorization, cookies, passwords, tokens, API keys, sessions, and private keys are replaced with [REDACTED];
• bearer/basic credentials and private-key blocks embedded in strings are replaced;
• JWTs, credential-bearing URLs, and common provider-token prefixes are replaced;
• object graphs and resources are never retained;
• request bodies and query values are not collected; only query key names and an explicit request-header allowlist are retained;
• matched request paths use Laravel's route template, so parameter values are never stored; unmatched failing routes collapse to /{unmatched};
• SQL bindings, comments, and literal values are not collected; SQL is stored as a bounded placeholder template;
• mail subjects, addresses, bodies, template data, cookies, session contents, and absolute application paths are not collected;
• depth, item, string, span, breadcrumb, trigger, envelope, and execution caps are enforced.

Review config/log-tracker.php for the exact defaults. The database, Blade UI, and notification adapters all consume the same sanitized representation.

Application-event breadcrumbs are opt-in and copy only explicitly named scalar paths:

The event object itself is never serialized.

Affected users

Authenticated request identifiers are HMACed with a key derived from APP_KEY and the immutable LogTracker installation ID. Only the 64-character digest enters an execution or signed queue envelope. Raw IDs, emails, names, and notifiable objects are not stored.

Use LogTracker::identifyUser($id) inside jobs, commands, or manual contexts. Pass null to clear the current execution identity. Retained distinct counts are repaired by log-tracker:prune and log-tracker:regroup.

Dedicated database connection

LogTracker clones the configured host connection under the separate log_tracker connection name. Laravel therefore creates a separate connection/PDO even when it points to the same local DBngin-managed server and database.

An incident can commit while the host connection later rolls back. Package writes are also ignored by the query watcher, preventing recursive capture. Three consecutive persistence failures open a process-local circuit for 30 seconds.

To use another database server, define a normal Laravel connection named log_tracker yourself and set:

The package connection name and the host source connection name must remain different.

Grouping and execution stories

• Fingerprints include environment by default, so staging does not contaminate production triage.
• Exception fingerprints use stable application path/symbol information, not line numbers.
• IDs and queue context follow W3C trace/span formats.
• One retained execution story may link to up to five independently grouped Issues.
• Repeated fingerprints update one Issue and create distinct occurrences.
• A resolved Issue reopens when a new occurrence arrives.
• Items can be assigned to a local developer handle, changed individually or in batches, muted, resolved, reopened, and unassigned.

Queue propagation

Async context uses a reserved _log_tracker payload envelope with:

• schema version;
• W3C traceparent;
• bounded origin name/environment/release;
• the already-HMACed affected-user digest, when present;
• up to five bounded origin breadcrumbs;
• an HKDF-derived HMAC tied to APP_KEY and the installation ID.

The envelope is authenticated metadata. LogTracker does not claim the top-level envelope itself is confidential or encrypted. Invalid, old, missing, or modified envelopes are ignored and the job starts with origin unavailable.

The default signed-envelope lifetime is seven days with five minutes of allowed clock skew. Change it only when delayed jobs legitimately need a different correlation window.

OpenTelemetry

The domain model is OpenTelemetry-compatible, but version 1.0 deliberately ships one native recorder and no OpenTelemetry runtime dependency.

The architecture spike found that the current Keepsuit integration offers custom processors but owns provider construction and defaults traces, metrics, and logs to OTLP. A separately installed Laravel package cannot guarantee auto-discovery order, safely mutate a provider that is already global, or promise that it never increases a host exporter's volume.

The native recorder keeps W3C-compatible IDs and queue context, so a future explicit interoperability adapter can be added without changing Issue, occurrence, or execution storage. See recorder decision.

Optional email and Slack notifications

Outbound notifications are disabled by default. When enabled, only the sanitized Item title, level, execution identity, environment, release, occurrence count, and dashboard URL are sent. Stack traces, execution context, breadcrumbs, and affected-user hashes are never included.

Configure these values in config/log-tracker.php or from /log-tracker/notifications. Dashboard overrides are encrypted with APP_KEY in the local log_tracker_system_state table. A saved Slack webhook is never rendered back to the browser; leaving the field blank preserves it, and removal requires the explicit checkbox.

Adapters use the host Laravel mailer and HTTP client. Delivery happens only after the incident transaction commits; a transport failure is diagnosed and never rolls back or changes host behavior. Muted Items do not emit reopen notifications. Dashboard links use the configured URL rather than the inbound request host, Slack control markup is escaped, and each worker enforces the configured per-minute delivery ceiling.

Runtime configuration

/log-tracker/configuration changes only operational settings that are safe to apply at runtime:

• incident-trigger log levels and slow request/query/HTTP/command/job/schedule thresholds;
• privacy-safe authenticated-user counting;
• bounded queue-origin breadcrumbs, envelope age, and clock skew;
• execution and resolved-Item retention windows.

Overrides are allowlisted, encrypted with APP_KEY, stored locally, and applied before watchers register on the next application boot. Saving applies the new values immediately to the current process. Reset removes only the encrypted override record and restores the published configuration and environment values; it never deletes captured data.

Structural policy remains file-controlled, including the database connection, route prefix/middleware, recorder, watcher enablement, redaction rules, capture limits, and installation ID.

Commands

Schedule pruning in the host application:

Uninstall

The uninstall command removes only LogTracker-owned database tables and the published config/log-tracker.php file. It asks for confirmation before deleting anything:

Use --keep-data to preserve captured incidents, --keep-config to preserve the published configuration, or --force for a reviewed non-interactive uninstall. The command removes its two migration records when it removes the tables, so reinstalling the package can recreate the schema normally. Combining --keep-data and --keep-config is rejected because it would remove nothing.

Upgrade from the alpha

Back up the application database, update the package, then run:

The upgrade command applies only this package's migrations, advances the published config contract to version 2 when it can do so safely, and records the schema/package version in the installation anchor. It never overwrites the installation ID.

log-tracker:regroup is preview-only by default. Use --write only after reviewing the projected Item count. New fingerprint groups inherit the first source Item's state. Alpha exception rows that predate stored exception-class metadata retain their previous group boundary instead of being guessed.

Runtime and failure boundary

Queue loop/stopping events and available Octane/Horizon lifecycle events clear all singleton execution and watcher state between operations. Successful roots still perform no package database writes. Fixed query-budget tests cap the Items page at four package queries, Issue detail at seven, Occurrences and Traces at two each, and global Search at four.

Failure isolation is best effort for catchable PHP/Laravel failures. The package cannot guarantee capture during SIGKILL, machine loss, irrecoverable OOM, engine termination, or before Laravel boots.

Develop

The Testbench suite verifies every capture surface, request/SQL/mail/ notification privacy, embedded secret detection, payload limits, observer and adapter failure isolation, grouping/regrouping, affected-user HMAC counts, dedicated transaction isolation, worker cleanup, installation upgrades, signed and expiring queue context, real trends, assignment/bulk actions, dashboard authorization and read-only rendering, optimistic state conflicts, automatic reopening, global search, occurrence/trace navigation, encrypted runtime settings, safe notification testing, guarded uninstall, fixed query budgets, and signed-cursor recovery. CI runs Laravel 11–13 plus SQLite, MySQL 8.4, and PostgreSQL 17 fixtures.

License

MIT. See LICENSE.md.