Session context

The last actions before submit, captured

Bugpot isn’t a full DOM replay tool — it’s the technical context a developer would ask for anyway. A rolling buffer of console and network activity plus the exact environment at the moment the reporter opened the widget, all attached to the issue without them ever opening DevTools.

Environment

Every browser detail you were about to ask for

Bugpot reads the runtime environment the instant the reporter opens the widget and attaches it to the issue. The answer to “which browser?” is already there before the ticket lands in your inbox.

Browser: Name, engine and full version
Operating system: macOS, Windows, iOS, Android
Viewport: Width × height at capture time
Device pixel ratio: 1x, 2x, 3x — the whole retina story
Page URL: Full path, query string and hash
Language & timezone: Reporter locale for reproduction
Connection: Effective type where the browser exposes it
Referrer: The page the reporter arrived from

Environment attached to the issue

{
  "browser":   "Safari 18.2",
  "engine":    "WebKit 620.1",
  "os":        "iOS 18.1",
  "viewport":  "390 x 844",
  "dpr":       3,
  "url":       "/checkout?step=payment",
  "referrer":  "/pricing",
  "language":  "en-GB",
  "timezone":  "Europe/London",
  "connection":"4g"
}

Console log

JavaScript errors, captured while they happen

The widget silently keeps a rolling console log from the moment it loads. When a reporter submits, the last few messages ship with the screenshot — including full stack traces on unhandled errors and promise rejections. No more asking anyone to open DevTools and read out red text.

console.log, console.warn, console.error captured with timestamps
Unhandled exceptions and promise rejections with stack traces
Buffered locally — nothing sent unless the report is submitted
Shown inline in the triage inbox next to the screenshot

Console — last 6 messages

10:14:02  log   "cart hydrated (3 items)"
10:14:04  log   "applied coupon SUMMER"
10:14:06  warn  "deprecated: window.legacyCheckout()"
10:14:09  log   "starting payment flow"
10:14:11  error TypeError: Cannot read properties of null
                at CheckoutButton.handleClick (checkout.js:184)
10:14:11  error Failed to fetch: POST /api/coupon
                net::ERR_INTERNET_DISCONNECTED

Network log

The recent API calls, alongside the screenshot

Bugpot watches fetch and XMLHttpRequest and keeps the last few requests with their method, URL, status code and duration. It’s often the difference between spending an hour reproducing a bug and finding a 500 in the ticket you were about to triage.

Rolling buffer of the last requests, capped in memory
Method, URL, status, duration — no request or response bodies
Masking selectors redact matching payload keys before capture
Filterable in the inbox by status class (2xx / 4xx / 5xx)

Network — last 5 requests

GET/api/session20038 ms
GET/api/cart20084 ms
POST/api/coupon204112 ms
POST/api/couponERR—
POST/api/payments/init5002.1 s

What it isn’t

Not full DOM replay — and that’s deliberate

Session-replay tools that record every DOM mutation, every input, every mouse move are useful, but they carry a real privacy and payload cost. Bugpot takes the opposite trade: enough context for a developer to reproduce, small enough to ship with every ticket, and quiet enough to leave running on production.

Nothing streams

Buffers stay in the reporter’s browser until submit. If they close the tab, nothing was sent.

Payload stays small

A few kilobytes of context per report, not megabytes of DOM diffs. Cheap to store, easy to search.

Masking always on

Sensitive selectors are blanked in the screenshot; matching payload keys are redacted in the network log.

Ship the context, not just the screenshot

Every report arrives with the environment, console and network already attached — free on every plan.

Start free See pricing