A Queuewatch alternative
for your whole Laravel app.

Laritor tracks exceptions, detects issues, and monitors Laravel performance. It helps you investigate failed jobs with their related queries, API calls, logs, and other recorded events. It also covers requests, commands, scheduled tasks, user sessions, server resources, feature flags, dashboards, in-app AI, and MCP.

Queuewatch focuses on Laravel queue failures, notifications, remote retries, failure resolution, and optional worker monitoring. Laritor provides broader exception tracking and application performance monitoring with related execution timelines. Choose Laritor when you want to understand both the failed job and the rest of your application; choose Queuewatch when its queue-specific recovery workflow is your main requirement.

Yes. Both are designed primarily for Laravel and have Composer packages that use Laravel concepts and events. Queuewatch also documents manual failure reporting through a REST API for other applications. Laravel native describes the primary product focus; it does not mean every tool with a Laravel integration has the same application coverage.

Yes. When your recording configuration retains the execution, Laritor includes its related recorded queries, outbound requests, logs, cache activity, and custom events. Inspect that timeline alongside the exception and job details. Events you disable, filter out, or do not instrument will not be available.

Yes. The released v1.3.1 package includes opt-in worker starts, heartbeats, memory, and stops on Laravel 12.20 or newer. It requires a running scheduler and shared persistent cache. Stop reason fields depend on the Laravel version. This is distinct from Laritor’s job execution, dispatch delay, queue wait, and throughput investigation.

Yes, on Pro and above after you enable the retry endpoint and configure its callback URL. The released client signs requests using the project API key, and only failures captured with retry enabled contain the serialized command needed to reconstruct the job. Laritor’s documentation does not list an equivalent dashboard-triggered retry endpoint; use your Laravel retry workflow after investigation.

It uses one failed-job occurrence count for both tools. One retained JobFailed occurrence is assumed to create one Queuewatch report. For Laritor, that count is multiplied by the average billable events recorded per failed job, including related activity and 2 KB increments. It estimates only the shared failed-job workload; recording requests, successful jobs, or other activity adds Laritor events.

No. It selects the smallest paid report allowance, starting with Pro for up to 1,000 failed-job reports, Team for up to 10,000, and Business above that. Extra project or team member requirements can require a higher tier even at a lower failure count. Trials and recurring free allowances are excluded.

Its public pricing shows $16, $48, and $160 per month with yearly billing and a 20% annual discount, alongside reference prices. The calculator uses those published annual monthly equivalents rather than inferring a monthly subscription rate. Laritor is shown at its published monthly rate. Confirm the billing term and current checkout price before subscribing.

The calculator shows “Ask for a quote” when the estimate is above $500 per month. Exactly $500 remains numeric. Queuewatch’s published Business allowance is unlimited failed-job reports; this does not imply unlimited API request rate, worker entitlement, or every enterprise option. Those details must be confirmed with Queuewatch.

Yes. Laritor offers in-app AI recommendations with configurable providers and a hosted read-only MCP server for exception details and recorded execution context. Your coding agent can inspect that context alongside your code to investigate a fix. Queuewatch documents REST integration and retries; an equivalent in-app AI assistant or MCP server was not found in the reviewed public documentation.

Yes. Exceptions-only retains configured events for executions with an exception. Issues-only retains configured events when an issue is detected, such as a failed job or slow request. Full observability retains all configured activity. Queuewatch reports failures through JobFailed and optionally worker lifecycle events; these products use different recording boundaries.

Laritor provides collection settings and client-side redaction before ingestion. Queuewatch’s released client can disable job payload collection and filters jobs, queues, and exception classes. Its older advanced configuration guide describes field scrubbing, but those settings are not present in the reviewed released configuration. Check the installed version, exception messages, and serialized retry data rather than assuming every sensitive field is masked.

Yes. Queuewatch explicitly supports Horizon, and Laritor can monitor Laravel job activity in an app that uses Horizon. Keep Horizon for running and managing your Redis workers. Queuewatch’s optional worker heartbeats still need a separate running Laravel scheduler and persistent shared cache; Horizon does not run the scheduler for you.

Yes. Install and configure Laritor alongside Queuewatch in a representative environment. Compare failure details, related events, alerts, billable usage, and combined collection overhead. You can keep Queuewatch for remote retries and worker lifecycle monitoring while evaluating Laritor’s broader application views.

Laritor starts recording new activity after installation and configuration. There is no documented automatic import of Queuewatch failure history. Keep access to your existing reports while Laritor builds a new record of your application.