Requirement: The must be installed on your web app
Note: Birdie collects logs only from your web app
Why Console Logs and Network Requests Matter
For complex troubleshooting—such as when an issue can’t be replicated in your own environment—console logs and network requests provide invaluable insights. These logs allow your team to diagnose problems more effectively without relying on customers to manually open developer tools or send screenshots of their logs.
Birdie collects:
Session and Device Metadata: URL, Timestamp, Country, Device, Browser, Operating System
Console Logs
Network Requests: Fetch, XHR
Enabling Console Logs and Network Requests
Ensure the is installed on your web appl.
and enable the collection of Console Logs and Network Requests.
What if my user has more than 1 window open?
If more than one browser tab is open with your web app, we will always display the console logs coming from the latest active tab (or window). If the user switches tabs during a recording, the console will also switch to the new focused tab, and it will be notified in the console flow with a "Tab switch" event.
What if Birdie doesn't collect all the logs ?
Console log recording systems captures logs generated within the web page’s JavaScript context. However, certain logs that users see in the browser console may not be captured due to the following limitations:
Browser and Extension Logs: Logs generated by the browser itself (e.g., warnings, deprecation notices) or by browser extensions (e.g., ad blockers, developer tools) are beyond the scope of our page-level JavaScript and cannot be intercepted.
Cross-Origin Restrictions: Logs from scripts loaded from other origins may be restricted by browser policies (like CORS), making them inaccessible for security reasons.
Direct Browser Logs: Some browser-level errors, like network failures (net::ERR_BLOCKED_BY_CLIENT), are directly logged by the browser to the console and do not pass through JavaScript console methods, meaning they cannot be recorded by our system.
These limitations are inherent to browser security models and cannot be bypassed by standard JavaScript execution within the web page.
What Happens to Sensitive Data in Network Requests?
At Birdie, we understand that network requests may contain sensitive information—such as tokens, cookies, or personal data. That’s why we’ve designed our system with privacy and security as a top priority.
Client-Side Filtering
When Birdie captures network requests during a screen recording, we proactively scan and sanitize all requests on the client side. This means any potentially sensitive data is removed before it ever reaches our servers.
Specifically:
We filter out sensitive fields from request headers.
If the request body is in JSON format, we scan and sanitize it as well.
This ensures that sensitive values are never transmitted to Birdie’s backend.
What You’ll See in Birdie
In your Birdie recording, any fields that were flagged as sensitive will masked with ***************
This indicates that we’ve scrubbed the original value for security reasons. Filtering happens before the recording is uploaded, so no unfiltered data ever leaves the device.
A Cautious Approach
We believe it's better to over-filter than under-filter. As a result, you might occasionally see information masked that isn’t truly sensitive. If you notice something that could be improved, we’d love your feedback—just reach out to us at security@birdie.so.
