Skip to content
Toado Docs

DevTools panel

The DevTools panel on the ticket detail page is what makes Toado tickets actionable. Instead of guessing what the user saw, you get the actual console log, network requests, errors, and performance metrics from the moment of capture.

The four tabs

Console

Every captured console.* call. Each entry shows:

  • Level: log, info, warn, error, debug. Color-coded.
  • Message: the serialized arguments. Objects are pretty-printed.
  • Timestamp: relative to page load.
  • Stack trace: where available, the call stack at the moment of the log.

Filter with the search box at the top of the tab. The filter matches message content, not levels, so search “TypeError” to find the relevant errors quickly.

Network

Every captured fetch and XMLHttpRequest. The table shows:

  • Method (GET, POST, PUT, etc.)
  • URL
  • Status (color-coded: green 2xx, blue 3xx, yellow 4xx, red 5xx)
  • Duration (ms)
  • Size (response size in bytes / KB / MB)

Click any row to expand. The detail view shows:

  • Request: method, full URL, request headers, request body (where present).
  • Response: status, response headers, response body (where size and CSP allow).
  • Timing: full waterfall (queued, blocked, DNS, connect, TLS, send, wait, receive).

For oversized responses, the body is truncated and a body_truncated: true flag is shown. The request and response headers are always captured fully.

Errors

Uncaught errors and unhandled promise rejections, captured via window.onerror and window.onunhandledrejection. Each entry shows:

  • Type: Error, TypeError, ReferenceError, etc.
  • Message.
  • Source file and line number.
  • Stack trace (multi-line).
  • Timestamp.

Errors are also surfaced in the Console tab as level=error entries; the dedicated Errors tab is a curated view focused on uncaught issues.

Performance

Captured at the time of the capture click:

  • Navigation timing: page load metrics (TTFB, FCP, DOMContentLoaded, load).
  • Long tasks: any task on the main thread > 50 ms during the capture window.
  • Web Vitals: LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), FID (First Input Delay), where measured.

Performance data is most useful for “the page felt slow” tickets. If you are debugging a layout bug, the Performance tab is usually unnecessary.

What is in this tab vs. the raw capture

Everything visible in the DevTools panel comes from the same capture payload that an MCP agent receives via get_ticket(include=['capture']). The UI is a presentation layer; the data is the same.

For programmatic access (e.g., grepping the network log for a specific URL), MCP gives you the data as JSON. For visual scanning, the UI is faster.

Filter techniques

Common patterns:

  • Console: filter “error” to surface every error-level message.
  • Network: filter the URL substring to find the relevant requests (e.g., “checkout” to find every checkout-related call).
  • Network: sort by Duration to find the slowest requests.
  • Network: sort by Status to surface 4xx and 5xx.
  • Errors: filter by error type to find a specific class.

Capture quality and DevTools data

Some pages produce partial captures. The DevTools panel respects what was actually captured:

  • CSP-locked sites: Console may be empty (in-page hook blocked). Network and screenshot are usually intact. The capture banner notes this.
  • Cross-origin iframes: Top-frame data is captured; iframe contents are not.
  • Streaming responses: The connection metadata is captured; the payload is not buffered indefinitely. Marked as streaming in the Network tab.

See Extension › Capturing › Edge cases for the full list.

Where to next