# How LaraBug works

Four words do most of the work in the rest of the documentation. They are worth two minutes.

## Applications

An application has its own keys, its own team, its own notification settings and its own history. An event belongs to exactly one application, and a plan's allowances are spread across all of yours.

Most teams run a separate application per environment: a production application and a staging application, so a staging mistake never pages anybody.

## Events

An event is one thing your application reported, and it counts towards one of two monthly allowances, repeats included:

* **Issues** are exceptions, JavaScript errors, CVE findings and detections. They are what a plan is priced on.
* **Telemetry** is everything underneath: requests, queries, logs, cache calls, mail, jobs, commands and scheduled tasks.

The two are counted apart. An account that has spent its telemetry allowance keeps receiving its exceptions, and the other way round.

That last part matters. An exception that fires ten thousand times in an hour is ten thousand events, which is why the Laravel client has a deduplication window and a sampling rate. Both are covered under [capturing exceptions](/docs/issues/exceptions).

## Issues and occurrences

An issue is a problem. An occurrence is one time it happened.

LaraBug groups incoming exceptions into issues by their class, their message and where they were thrown, so a `QueryException` from one endpoint is one row in your list however often it fires. Opening it shows the latest occurrence with its full context, and the ones before it.

You read issues. You count occurrences.

## Retention

Occurrences are kept for as long as your plan says, between 7 and 365 days, and then they rotate out. The issue itself stays, so the history of what broke survives; the individual reports behind it do not.

Nothing is deleted early, and nothing is kept late. If you need a report to outlive its window, export it before it goes.

## What happens to an event

1. Your application catches something worth reporting and hands it to a client.
2. The client filters it: your environment list, your ignore rules, your deduplication window, the fields you have told it to scrub.
3. What is left is posted to LaraBug over HTTPS.
4. LaraBug groups it into an issue, stores the occurrence, and tells whoever asked to be told.

Step two happens on your server, before anything leaves it. That is the part to read carefully if you log personal data: see [filtering sensitive data](/docs/guides/filtering-sensitive-data).