stableFor organization owners, admins and CI maintainers

Usage and limits

Your plan limits how many screenshots your organization can upload each month, how many projects and seats it has, and how long build history is kept. This page explains the screenshot allowance and the limits on each upload. Billing covers plans and seats.

See your usage

  • Usage & capacity: open the organization switcher and select Usage & capacity. The cards show Screenshots this month, Monthly allowance, Allowance remaining and Effective seats. The Screenshots and allowance chart shows screenshots captured per day, and a stepped line for the allowance at that time. Usage by project shows which projects use the most.
  • Billing & usage → Usage & Quotas shows screenshots, projects and seats against their limits, and your screenshot pack credits.
  • The usage chip in the header turns amber at 70% of the monthly allowance and red at 90%. At 100% it says Limit reached. Hover over it to see what’s left, including pack credits.
  • A project’s Usage page (select Usage in the project sidebar) shows builds and screenshots over time for that project. It also counts screenshots of removed snapshots, so its totals can be higher than what counts toward your allowance.

What counts as a screenshot

Each snapshot in a build counts once. A snapshot is its name plus viewport, browser and device scale, so one test captured at three viewports counts three times.

  • Uploading the same snapshot again in the same build doesn’t count again.
  • A snapshot the client confirms as unchanged without re-uploading the image still counts.
  • Removed results don’t count.

Monthly allowance

The allowance resets at 00:00 UTC on the first day of each calendar month, whatever your billing date.

  • Free: a fixed number of screenshots per month.
  • Pro: a number of screenshots per seat, multiplied by your seats. When you add seats, the allowance goes up at once. When you remove seats, it goes down the next month, because pixmoat uses the highest seat count you had this month.

The pricing page lists the current numbers, and Monthly allowance shows yours.

Screenshot packs

A screenshot pack adds a one-off number of screenshots on top of the monthly allowance.

  • Packs hold 10,000, 50,000 or 200,000 screenshots. The owner or an admin of a Pro organization buys them in Billing & usage → Buy Screenshot Packs by selecting Buy Pack. Checkout goes through Creem, like a subscription.
  • pixmoat uses pack credits only after this month’s allowance is used up. The oldest pack is used first.
  • Unused credits carry over from month to month, and expire 365 days after purchase.
  • Screenshot Pack Credits on Billing & usage shows each pack’s Credits Remaining and when it Expires.

Credits you already have keep working if the organization moves back to the Free plan.

When screenshots run out

pixmoat warns you before the allowance runs out:

  • At 80%, Billing & usage shows “You’ve used n% of your monthly snapshots.”
  • At 95%, a message says “You’re about to hit your snapshot limit.” once per session.

Once the allowance and every pack credit are used up, Billing & usage shows “Your monthly snapshot quota is exhausted.” New screenshots are rejected until the allowance resets. pixmoat doesn’t send an email about this, so keep an eye on the header chip.

In CI, the Playwright client prints an error such as:

Failed to upload snapshot "home" (409): {"error":"quota_exceeded","quota":"snapshots_per_month","message":"Free plan is limited to <limit> snapshots_per_month.", ...}

An error like this may also say Confirm unchanged failed (409): quota_exceeded. Because an upload failed, the client finishes the build as Failed, and the build doesn’t count as capture complete.

To upload again:

  • Pro: buy a screenshot pack, or add seats (the extra allowance applies at once).
  • Free: upgrade to Pro (see Billing), or wait for the monthly reset.

Then run the pipeline again.

To use fewer screenshots, capture fewer viewport and browser combinations on feature branches, or skip visual tests for changes that can’t affect the UI.

Upload limits

These limits apply to every plan. The Playwright client prints the response code and message, for example Failed to upload snapshot "checkout" (413): ....

ResponseMessageWhyWhat to do
413image exceeds max upload sizeA single image is larger than 20 MiB.Capture a smaller area, use a lower device scale, or split a long page into several snapshots.
413image exceeds processing memory budget; reduce capture dimensions or device scaleThe image has too many pixels to compare, usually a long full-page capture at device scale 2 or 3.Capture a smaller area, use device scale 1, or split the page.
413request body exceeds 2097152 bytesA request other than an image upload, such as starting a build with a large .pixmoat.yaml, is larger than 2 MiB.Make the file smaller.
408upload body timed outThe upload stalled for 10 seconds, or was too slow.Check the CI runner’s network connection to app.pixmoat.com and run the job again.
503image processing busy; retry laterpixmoat was busy processing other uploads.Nothing, usually. The client waits and retries by itself (see below). If the job still fails, run it again.
429too many authentication requests; retry laterToo many sign-in, sign-up or password requests came from your network in a short time. CI uploads aren’t rate-limited this way.Wait a moment and try again.

pixmoat scales down very wide or very tall images before it stores them, as long as they stay within the limits above.

Retries in the Playwright client

The client retries a screenshot upload up to four times when pixmoat answers 429 or 503. It waits a little longer each time, and honors the Retry-After header up to 10 seconds. All attempts share the request’s time limit (30 seconds unless you set PIXMOAT_REQUEST_TIMEOUT_MS, see Client environment variables).

It doesn’t retry 408, 409, 413, network errors or other requests. It records the failure and finishes the build as Failed, so a partial run never retires baselines. Fix the cause and run the pipeline again.