Features & functionality

Which data does Bird Eats Bug capture and log?

Last updated on
February 28, 2023

Visual data recording

Tab video recording

Video recordings of a specific tab only include things shown in that tab. Unexpectedly this means that native HTML selects, for which the browser uses native operating system UI, are not visible in tab recordings. Neither are contents of popups. If your recording needs to include interaction with such elements, please select the “record your screen” option. These options also allow to record video outside of the browser, although Bird can’t capture technical information of user interaction with any program outside the browser.

Replays (DOM mutation recording)

As mentioned on the feature site, the visual part of replays are implemented as DOM recordings, and uses the rrweb library under the hood. The benefit of this technology is that it is - on most pages - a faster and more light-weight alternative to video recording, which is why it can be done continuously in the background and does not need to be started and stopped like our video recording feature. Since this technology is still young there’s still some quirks. Additionally, DOM recording has the fundamental trait that nothing outside the DOM can be recorded. This latter limitation means that only content on the specific page is recorded: Data in popups or other tabs is not recorded, neither is anything outside the HTML document like native MacOS/Windows menus shown for native HTML selects.

On top of that, some embeddable elements like <canvas> are not recorded (e.g. Google Maps, Figma).

When playing back DOM recordings, there can also be visual glitches, like duplicate elements being shown. Even when there’s no obvious glitches, a DOM recording is unlikely to look exactly like the page as experienced by the session reported. Security configuration like CORS on the recorded site’s hosting, and Bird’s own CSP policy can prevent the loading and rendering of embedded elements, like the original page’s font. Because DOM recordings don’t include all information (e.g. image files are only linked to), DOM recordings can drift apart from the time of the recording in fidelity over time, if the content of the asset behind the URL changes, or even degrade, or when the assets are no longer accessible at all at the URL.

To provide a higher level of control, when using the Web SDK, it is possible to customize the rrweb options, as documented here.

System Information recording

The System Information pane shows the following information:

  • Internet download speed and latency
  • Operating system platform and version e.g. macOS, Windows
  • Browser with version
  • Browser Engine
  • Screen resolution
  • Window resolution
  • Device type e.g. Desktop
  • Vendor
  • Locale
  • Timezone
  • Bird application version

Operating system version

As of MacOS version 10.15, Apple has limited the recording of the precise system version more details here, so Bird is limited to only be able to show that the MacOS version is later than 10.15.7.

Internet download speed and latency

The measured values are approximations, since network conditions constantly change, and the connection speed to a server can be quite different from site to site. navigator.connection is used as base information source, but since the download speed measured is capped at 10mbps, Bird downloads a 1MB file from a CDN to gauge a better approximation of the downlink. In areas of the world where the CDN does not host nodes close by, the measurement is likely to be less precise.

Technical data recording

The browser extension records a number of technical data types, listed below. You can also enable or disable recording any of them in the extension recording settings page, that can be accessed by copy and pasting this link in a new tab:


Replay screen recording

  • DOM mutations

Console pane

* for these console methods, we only record the method call. We are unable to record the output values because these methods depend on context that the extension does not have (e.g. were console groups already opened before the session was started? Were counts already initiated before session recording began?), trigger side-effects we don’t have access to (profiles), or where computing the output would be plausible but imprecise (time method). Hence we decided to show such console method calls only as they happened, without output. Knowing that these methods were called can be helpful to understand the executed code path, and thus help debugging an issue.

Network pane

Framework/Library Support

When React or Vue.js components are logged from one of the mentioned console methods, they are rendered so that they are easy to understand.

The browser extension does not offer special recording abilities for state libraries like Redux, and instead focuses on providing most value independent of a site’s specific tech-stack.

However, we have noticed that technical data recording on AMP pages is prone to missing technical data, due to the use of iFrames to wrap the main content.

Missing recording capabilities

Most of these items are existing feature requests:


Please note that only click events that reach the document level are recorded.


Please note that only keydown and input events that reach the document level are recorded.

Network request recording

Network request recording has more caveats than other recorded data types. There are two reasons for that:

  • Frequency and size of network requests
  • Browser APIs allowing to access network request information

Frequency and size of network requests

Pages can execute hundreds or even thousands of network requests per minute. They can contain large payloads. Recording all data flowing over the browser’s network can easily accumulate hundreds of Megabytes of data in short time periods. Therefore we have to put reasonable limits in place for the capture of network request recording, frequency and size of network events, in order to avoid these potential problems:

  • Slowdowns of the browser / operating system / recorded pages
  • Running into storage limits
  • Painfully slow session uploads
  • An increased likelihood of Bird or the recorded page crashing

This does, however, mean making certain trade-offs in the way we record network requests to avoid the aforementioned issues:

  • Response bodies are only recorded if their payload size is not more than 1MB.
  • Response bodies are only recorded if the Content-Type header is one including json or text. Bird does not attempt to capture binary information like images, videos, or files like PDFs (which also tend to have larger payload sizes than the mentioned 1MB).

Browser APIs allowing to access network request information

The WebRequest browser extension API does not allow the capture of network request responses (at least in Chromium based browsers).

Since response information is likely to contain crucial information for debugging, Bird additionally instruments fetch and XMLHttpRequest, which is the approach taken by client-side monitoring tools such as Sentry.

Just using the fetch and XMLHttpRequest monkey-patching does not allow to record requests issued by the browser (on page load, form submission,…). For this reason, Bird employs the WebRequest extension API for all request types except for fetch and XMLHttpRequest, and instead records these by instrumenting fetch and XMLHttpRequest. Due to the different data sources, the timing / order of requests can potentially slightly differ from the actual timing / order.

Web socket messages are currently not recorded.

In conclusion, while we are constantly making improvements on the recording of network requests, due to reasons outlined above, there will sometimes be instances where response bodies are not shown.

Stop reporting bugs the old-fashioned way

Try Bird on your next bug - you’ll love it

“Game changer”

Julie, Head of QA


Overall rating: 4.7/5

Try Bird later, from your desktop