# What opens an issue An issue is one problem in your application, with every time it happened behind it. Two kinds arrive as issues: an [exception](/docs/issues/exceptions) the client caught, and a [vulnerable package](/docs/issues/dependencies) it found in a lockfile. Twenty more are read out of the telemetry: a route that got slow, a job that keeps failing, a task that stopped running. Nothing has to be thrown for those; each is a reading the panel keeps watching, and the issue opens the moment the reading crosses the threshold the application sets for it. They all land in the same list, and the list treats them the same. ![The issue list in the panel: exceptions, CVE findings and detections side by side, each with its application, its owner and the day's activity](/images/docs/issues.png) ## Exceptions Everything the exception handler reports, and everything you hand to `report()`, arrives with the request, the user and the source around the line that threw. The same exception from the same place is one issue with many occurrences. [Exceptions](/docs/issues/exceptions) has the switches, the environments and how to leave some out. ## JavaScript errors The browser packages report what breaks in the page, mapped back to your source with [source maps](/docs/javascript/source-maps), into the same list as the server's exceptions. Start at the [JavaScript installation](/docs/javascript/installation). ## Deprecations Each deprecated call PHP reports is grouped per line of code, so one issue says where the next major version will bite. They come in through the [log channel](/docs/telemetry/logs#deprecations). ## Dependency findings The client reads `composer.lock`, and the npm lockfiles when you have them, and every night the panel checks them against the advisory database. Each application gets one issue listing every vulnerable package and the version that fixes it. [Dependencies](/docs/issues/dependencies) says what is scanned and when. ## From requests Four kinds are read out of [request tracking](/docs/telemetry/requests), so they need it switched on. ### Slow routes A route whose p95 has gone past the threshold the application sets. ### Error rates A route failing more often than it should, counted over its 4xx and 5xx responses. ### Large responses A response grown past the size you set, which is usually a page that started returning something it should not. ### High memory A route whose p95 memory spikes above the threshold. ## From outgoing calls Calls through Laravel's HTTP client travel with the [request](/docs/telemetry/requests) that made them. ### Failing dependencies An outgoing call that keeps failing, named by its host. ### Slow dependencies An outgoing call that got slower than it used to be. ## From queries Statements travel with the [request](/docs/telemetry/requests) that ran them, and the [Queries](/docs/telemetry/queries) page ranks them. ### Slow queries One statement, timed, with the route it runs on. ### N+1 queries The same statement repeated through one request, which is the signature of a missing eager load. ### Missing indexes A scan reading far more rows than it returns. The client has to send query plans for this one; [Queries](/docs/telemetry/queries#query-plans) says how. ## From queue jobs Read out of [queue job tracking](/docs/telemetry/queue-jobs), which is on by default. ### Failing jobs A job class failing more often than it should, with the exception that killed it. ### Slow jobs A job taking longer than it used to. ### Queue backlogs Ready jobs waiting longer than they should on one queue, which is usually a worker that died. ## From scheduled tasks and commands Read out of [scheduled task](/docs/telemetry/scheduled-tasks) and [command](/docs/telemetry/commands) tracking, both off until you switch them on. ### Failing schedules A scheduled task that keeps failing. ### Stopped schedules A task that should have run and never fired: the cron that quietly stopped. ### Failing commands An Artisan command exiting with an error. ## From mail and notifications Both travel with the [request](/docs/telemetry/requests) that sent them; [Mail and notifications](/docs/telemetry/mail-and-notifications) says what is kept. ### Failing mail A mailable that will not go out. ### Failing notifications A notification a channel keeps refusing. ## From cache ### Low cache hit rates A key prefix missing more than it hits, read out of the [cache operations](/docs/telemetry/cache) a request made. ## From logs ### Logged errors Errors written to the [log channel](/docs/telemetry/logs) without an exception behind them. ## One list, whatever the kind Every issue has the same handles. Hand it to someone, give it a priority, snooze the ones you already know about, and say what causes it in the thread; every change is on the trail. An issue you marked fixed that comes back reopens itself, so a regression is never a second issue. [Alerts and notifications](/docs/guides/alerts-and-notifications) work the same way for all of them: a new issue, one that came back, or one of a kind you asked to hear about, where your team already is. ## Opening and closing An exception stays open until somebody marks it fixed. A detection opens itself when its reading crosses the threshold and, for most kinds, closes itself once the reading has stayed clear for a while, so a slow afternoon does not leave a stale issue behind. The thresholds are per application, in its settings in the panel. ## What it costs Every exception counts towards your monthly issues allowance, repeats included, which is what deduplication and the ignore lists on the [Exceptions](/docs/issues/exceptions) page are for. A detection is read out of telemetry that is already counted, so it adds nothing to the bill. [What LaraBug records](/docs/telemetry/overview) has the telemetry's own switches and costs.