View docs

About Laritor

Built from real
Laravel problems.

Laritor began with a familiar production problem: knowing something went wrong, but missing the context to understand why.

Today, it helps Laravel developers track exceptions, find issues, and monitor performance, with the related events connected in one place.

Read the story

Where it started

The hardest problems
left very few clues.

A customer could not submit a form. Recommendations disappeared at checkout. Payments became slow. Users ran into problems we could not reproduce later.

Often, nothing had crashed. These issues depended on a user role, session data, cached data, timing, a background job, a feature flag, or a particular application state.

Logs rarely held enough context. Metrics could show a slowdown, but understanding exactly what happened during one request was still difficult.

A form that will not submit

One customer hits a problem that other users never see.

A checkout that slows down

A payment or API call takes longer than expected.

A bug you cannot reproduce

The session, cache, or application state has already changed.

Why Laritor was built

Understand what happened.
See it all together.

I wanted monitoring that understands how Laravel works. A request should connect all the work that happened inside it, in the order it happened.

Queries, cache activity, jobs, mails, notifications, outbound requests, logs, and exceptions belong together. Developers should be able to understand a production request in one connected view.

You can record only exceptions, record detected issues, or record all activity. Each recorded request or job includes its related events, so you can start with the problems you care about.

Explore request monitoring
POST /checkout Example request
  1. Database query

    Load the order

  2. Cache

    Read the customer’s cart

  3. Feature flag

    Choose the checkout flow

  4. Outbound request

    Call the payment provider

  5. Application log

    Record what happened

  6. Exception

    See where the request failed

Related events. One request. The full picture.

Talking with other teams

Other teams were facing
the same problem.

Conversations with engineering leaders at other companies made the pattern clear. Teams struggled to reproduce production-only issues and wanted a deeper view of their Laravel applications.

Those conversations confirmed that the need was shared. They also reinforced what I care about: helping developers spend less time guessing and more time solving real problems.

The journey

From the first commit
to the product you see today.

Explore the changelog

  1. The first commit

    The initial commit to the Laritor Composer package marked the beginning of a monitoring platform built specifically for Laravel.

    View the initial commit

  2. Laravel Nightwatch was announced

    Learning that the Laravel team was building something so close to Laritor was a shock. I had already invested deeply in the product and faced a real choice: continue or stop. I decided to keep building, knowing I would face strong competition from the Laravel core team.

    Read my reaction

  3. Laritor was introduced

    After more than a year of development, iteration, and solving hundreds of edge cases, Laritor was introduced publicly.

  4. The first paying customer

    The first paid subscription showed that someone trusted Laritor enough to pay for the value it provided.

  5. An interface shaped by feedback

    Laritor’s interface was substantially refactored around the daily workflows customers shared with us.

  6. Featured on Laravel News

    Laravel News featured Laritor in an article about debugging production Laravel apps, covering connected request timelines, queue insights, dashboards, and AI analysis.

    Read the Laravel News feature

  7. Featured on Laravel Daily

    Povilas Korop featured Laritor on Laravel Daily, showing how it monitors requests, queries, jobs, and logs in a Laravel project.

    Watch the Laravel Daily feature

  8. A completely redesigned Laritor UI

    A cleaner interface, easier navigation, clear predefined filters, and performance metrics brought a more consistent experience across Laritor.

    Explore the redesign
  9. Today

    Still built with customers

    Laritor continues to evolve through direct feedback from the Laravel developers and teams who rely on it.

Learning from customers

Slow growth.
Meaningful progress.

At first, almost every customer was on the free plan. I wondered whether the product was good enough, or whether Laravel developers cared about observability.

I started talking directly with users. Those conversations changed Laritor. Many features available today came from customers explaining what they needed in their production workflows.

On November 9, 2025, Laritor received its first paid subscription. Someone trusted the product enough to pay for it. That confidence made it easier to keep building and listening.

The first paying customer.

Payment notification confirming Laritor’s first paid subscription on November 9, 2025
A small milestone that meant a lot.
1B+

events processed per month

Read about the architecture

Laritor at scale

Built for the apps
you run in production.

Laritor processes more than a billion events per month. Customers use it in high-traffic Laravel applications to understand their exceptions, issues, and performance.

Keeping monitoring overhead low is central to the architecture. We share how the ingestion pipeline works and the decisions behind it on the Laritor blog.

A personal commitment

Keep listening.
Keep making Laritor better.

I started Laritor to build the monitoring tool I wished existed while leading engineering teams. Customer conversations still shape the product, and every feature starts with a real production problem.

My commitment is to keep improving Laritor for the Laravel developers and teams who depend on it.

SrinathFounder of Laritor
Start monitoring for free Get in touch