How to Improve Logs Capture with Birdie
Why some logs don’t appear in Birdie
When you use Birdie’s screen recording and log capture features, you might sometimes notice that fewer logs appear in Birdie than in your browser’s Developer Tools console. That’s expected — and here’s why.
Birdie runs inside your web application, not inside the browser itself. It can see what your app’s JavaScript is doing, but not what the browser internally reports about it.
Your app’s code
console.log('Request failed:', error)
✅ Yes
This is generated by your own JavaScript code, which Birdie can capture.
Browser internals (Chrome messages)
GET https://api.example.com failed (net::ERR_CONNECTION_REFUSED)
❌ No
This message comes from Chrome’s internal network layer, which no page script can access.
So the “missing” logs are not lost — they simply belong to the browser, not your app.
How Birdie captures logs
When installed in your app, the Birdie snippet automatically captures:
All standard
consoleoutputs (log,info,warn,error)Network activity made through
fetch()andXMLHttpRequestUncaught JavaScript errors and unhandled promise rejections
In short, Birdie records everything your code says or does, but not what Chrome adds on its own.
How to improve log visibility
You can help Birdie capture more meaningful logs by explicitly logging caught errors.
✅ Example: logs Birdie can capture
try {
const response = await fetch('/api/data');
if (!response.ok) {
console.error('Request failed with status:', response.status);
}
} catch (error) {
console.error('Network error:', error);
}❌ Example: logs Birdie cannot capture
// Chrome will show a "GET /api/data failed" message in DevTools,
// but Birdie won’t see it, because your code never logged it.
const response = await fetch('/api/data');
const data = await response.json();How to tell the difference
When checking the browser console:
Messages with file/line references of your code (like
main.js:42) → ✅ from your page → captured by BirdieMessages with file/line references of tird-party code (like
library.lambda.js:287) → ⚠️ from your page → may be captured by Birdie if the library logs errors in your page's consoleMessages without file references or
(index)/VMxxx→ ❌ from Chrome internals → not captured
This simple clue helps you quickly spot what Birdie will or won’t record.
Summary
Console logs (log, warn, error) from your code
✅ Yes
console.error('API failed')
Network logs from your code (fetch, XHR)
✅ Yes
fetch('/api/data')
Browser-generated console messages
❌ No
GET ... failed (net::ERR_CONNECTION_REFUSED)
Third-party scripts or extensions
⚠️ Maybe
Only if they log via your page’s console.
Developer Best Practices
To get the most complete and useful logs in Birdie recordings:
Wrap async operations in
try...catchand log any caught errors.Use clear, contextual messages — e.g.
console.error('[Auth] Login failed', error).Log both context and value (URLs, status codes, IDs, etc.).
Avoid silencing errors — don’t leave empty
catchblocks.Standardize your logging style across the app.
These habits make Birdie recordings much more useful for debugging.
Last updated