Plans, limits, and usage

Pricing is based on how many bugs you collect. There is no per-seat pricing and no enterprise tier gated behind a sales call.

Comparison

Prices are per month and exclude tax. Paddle, which handles billing, adds any tax due at checkout.

The free plan is a real plan

500 widget reports a month per project, three projects, no expiry, no card. For a side project or an early-stage product, that is often enough indefinitely.

What you give up is integrations, webhooks, branding removal, and custom properties, and reports are kept for 30 days. Session replay, screen recording, email notifications about new reports, and the MCP server for Claude Code and other AI assistants are included on every plan, Free too.

The five built-in task fields — status, assignee, priority, labels and due date — are on every plan, and so is editing them: a Free project can rename its priorities, recolour them, add its own and delete the rest. Custom properties means fields you define on top of those five.

On Free, new reports reach you by email and in the app's notifications. Posting them to Telegram, Slack, Discord or your issue tracker is what Pro adds.

How long reports are kept

A report is deleted once it is older than your plan keeps reports — 30 days on Free, 90 on Pro, 365 on Ultra — together with its screenshots, recordings, session replay, console logs and network requests. The task it belongs to stays, with its description, comments, activity and properties, and a task whose reports have all expired keeps its place on the board.

Deleted reports free their storage at once. The window follows the owner's current plan: after a downgrade, or while a subscription is paused, reports older than the new window are deleted within a day. An upgrade lengthens the window from then on, but a deleted report does not come back.

Which limit you will hit first

Storage, usually. Screen recordings and session replays are much larger than console logs. A project well under its report count can still fill 1 GB if most reports include recordings.

If storage is the constraint, consider setting screenRecordingMethod: 'dom' (rrweb recordings are considerably smaller than video) or disabling recording where it is not needed.

Reports per month, on a public-facing app. 500 a month goes quickly once real users find the button.

Reports per minute, almost never — unless something goes badly wrong. That limit exists to protect you from a broken deploy generating hundreds of reports in a burst, or a leaked key being abused.

What happens at a limit

Monthly report limit reached. The widget stops accepting reports until the 1st of the next month, 00:00 UTC. It tells the reporter "This site is not accepting feedback right now" and disables Send, so nobody types a report that is then lost — but no new reports reach you until the count resets. Reports a member adds by hand in the dashboard do not count. This is the limit worth watching, so the project owner is warned in the app and by email at 80 %, 90 % and 100 % of the month's limit.

Monthly error limit reached. The project stops accepting error events until the 1st of the next month, 00:00 UTC, and the SDK stops sending them from a page once one is refused. Every occurrence counts, repeats of a known error and ignored errors included. The limit is separate from widget reports, which keep arriving. The owner is warned in the app and by email at 80 %, 90 % and 100 %.

Distinct error limit reached (Free). A new kind of error is no longer recorded; repeats of errors already on the list are still counted. Errors with no task that have not been seen for 90 days are deleted daily, which makes room again.

Source map limit reached. Uploading more maps fails. Nothing is deleted to make room, and the maps already uploaded keep resolving stack traces.

Storage limit reached. Uploads fail. Reports may still be created without their attachments.

Rate limit reached. Submissions are rejected until the window resets. Normal traffic will not hit this.

Member limit reached. Invitations fail with an error. Existing members are unaffected.

Custom property limit reached. Creating another property fails. Existing properties and their values are unaffected. On a Free project the control is replaced by an upgrade message rather than failing on save.

Options per property reached. Saving the option list fails. The cap is checked against the net change, so swapping ten options for ten others is fine at the limit. It applies to labels and board columns too, since those are options as well.

Project limit reached. Creating a new project fails. Existing projects are unaffected.

Integrations after a downgrade. Integrations need Pro or Ultra. On Free, existing ones stop sending and show as Paused; the owner can still disconnect them, and an upgrade turns them back on.

Limits are enforced per project, and the project owner's plan is what applies. Members do not need their own paid plan.

Checking usage

The project settings page shows this month's widget reports and errors against their limits, the date the counts reset, how long reports are kept, and source map storage, alongside your other limits. From 80 % of the monthly limit it also shows a notice. The report limit is the one that stops new bugs reaching you, so it is worth a look before your count matters.

Upgrading

Billing is handled through Paddle. Upgrades take effect immediately, and the new limits apply at once — an upgrade is the fastest fix for a project that has stopped accepting reports.

Reducing usage without upgrading

• Disable screen recording where it is not needed — the biggest single storage saver

• Use dom capture methods, which produce smaller artifacts than video

• Filter network capture to your own endpoints, cutting report size

• Separate projects per environment, so staging noise does not consume production allowance

See also

• Team members, roles, and permissions

• Custom properties: adding your own fields to tasks

• Customizing priorities

• Feature toggles and handling sensitive data

• Capturing JavaScript errors automatically

• Working with captured errors

• Readable stack traces: uploading source maps