Plugins
Everything past the core error-tracking dashboard — alerting, release tracking, Linear sync, HTTP ingest, access-log analytics — is an optional plugin. This keeps a fresh install lean: nothing but the dashboard and file-based log parsing is on by default, and each plugin is toggled per application in Settings → Plugins.
The toggle contract
- Off means off. A disabled plugin's API routes return a plain
404— not a "coming soon" message, an actual 404, identical to hitting a route that doesn't exist — and its Settings UI section and any sidebar entry it adds (e.g. Access logs) disappear entirely. - Per application, not global. Application A can have Alerting on while application B doesn't, because each application is a fully separate, isolated database (see Applications).
- State survives upgrades safely. Which plugins exist, and their sensible defaults, ship with the code. Which ones you turned on or off is stored per application, layered on top of those defaults — so upgrading Log Lens to a version that adds a new plugin never silently turns it on for an existing application.
The five built-in plugins
| Plugin | Default | What it does |
|---|---|---|
| Alerting | Off | Slack, Discord, or webhook notifications on new errors, reoccurrences, and spikes. |
| Release tracking | Off | Records deploys, attributes each issue to the release(s) it appeared in, and links source frames to your code host. |
| Linear integration | On | Pulls matching Linear issues into the dashboard and mirrors status changes back. |
| HTTP ingest | Off | Accepts pushed error events over HTTP — the transport behind the capture SDKs. |
| Access-log analytics | Off | Turns the nginx access logs Log Lens already parses into a traffic / status-code / top-path view. |
Linear defaults on because pulling in an issue tracker you already use is a reasonable thing to want immediately after install; everything else is opt-in until you ask for it.
How toggling actually works
Each plugin is a small class stating its id, display name, category, and default state — plus, for the four that expose an API, the specific routes it owns. Settings → Plugins just flips one flag per plugin id, stored as a single JSON blob per application. There's no per-plugin database migration to run or config file to hand-edit: flipping the toggle takes effect on the very next request, and flipping it back off leaves any data the plugin created (deploys, alert rules, pulled Linear issues, …) in place, just inaccessible until re-enabled.
A plugin isn't a separate install
Every plugin ships in the same Log Lens codebase and shares the same database as the core dashboard — enabling one doesn't download anything or provision a new table on the fly (the tables already exist from the base schema). "Optional" here means hidden and inert by default, not a separate product.