# How to Improve Logs Capture with Birdie

{% hint style="info" %}
**TL;DR** — Birdie captures all logs your application code generates (via console.log, console.error, fetch, etc.), but cannot access Chrome’s internal console messages like GET ... failed net::ERR\_CONNECT
{% endhint %}

***

### 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.

| Source                                  | Example                                                            | Captured by Birdie? | Why                                                                                       |
| --------------------------------------- | ------------------------------------------------------------------ | ------------------- | ----------------------------------------------------------------------------------------- |
| **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 `console` outputs (`log`, `info`, `warn`, `error`)
* Network activity made through `fetch()` and `XMLHttpRequest`
* Uncaught 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

```js
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

```js
// 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 Birdie
* **Messages 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 console
* **Messages 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

| Log Type                                             | Captured by Birdie | Example                                        |
| ---------------------------------------------------- | ------------------ | ---------------------------------------------- |
| 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:

1. **Wrap async operations in `try...catch`** and log any caught errors.
2. **Use clear, contextual messages** — e.g. `console.error('[Auth] Login failed', error)`.
3. **Log both context and value** (URLs, status codes, IDs, etc.).
4. **Avoid silencing errors** — don’t leave empty `catch` blocks.
5. **Standardize your logging style** across the app.

These habits make Birdie recordings much more useful for debugging.

***

<details>

<summary>Advanced: Understanding Browser-only Logs</summary>

Besides network failures, the browser prints many other **internal messages** in DevTools that **no web app (and therefore no Birdie snippet)** can access.\
Here are the main categories.

#### 🔒 1. Browser Security & Privacy Warnings

Examples:

```
Mixed Content: The page at 'https://example.com' was loaded over HTTPS,
but requested an insecure resource 'http://api.example.com'.
```

```
Cookie “sessionid” has been rejected because it is already expired.
```

```
[Deprecation] The cookie attribute “SameSite=None” requires “Secure”.
```

```
Blocked autofocusing on an <input> element in a cross-origin subframe.
```

These messages come from Chrome’s security layer — not from your app code.

***

#### ⚙️ 2. Deprecation & Feature Warnings

Examples:

```
[Deprecation] The ‘keyboardevent.keyCode’ property is deprecated. Please use ‘keyboardevent.key’.
```

```
[Violation] 'setTimeout' handler took 300ms
```

```
Synchronous XMLHttpRequest on the main thread is deprecated.
```

They indicate outdated browser APIs being used, often by libraries.

***

#### 🌐 3. CORS & Network Policy Errors

Examples:

```
Access to fetch at 'https://api.example.com' from origin 'https://app.example.com'
has been blocked by CORS policy.
```

```
Failed to load resource: net::ERR_BLOCKED_BY_CLIENT
```

These are thrown *before* your JavaScript receives any response, so your code never sees them.

***

#### 🧩 4. Extension or DevTools Messages

Examples:

```
[AdBlock] Blocked request to 'https://ads.example.com'
```

```
[MyExtension] Injected script loaded successfully.
```

These logs come from browser extensions or tools, not from your site’s context.

***

#### 🎨 5. Rendering, Performance, and CSS Warnings

Examples:

```
[Intervention] Slow network is detected. Fallback font will be used...
```

```
Error parsing CSS stylesheet: Unknown property ‘user-drag’.
```

```
Layout was forced before the page was fully loaded. Consider marking the script as async.
```

They’re emitted by Chrome’s rendering engine.

***

#### Summary Table

| Type of Console Message         | Example                               | Captured by Birdie? | Source               |
| ------------------------------- | ------------------------------------- | ------------------- | -------------------- |
| App-level console logs          | `console.error('API failed')`         | ✅ Yes               | Your JavaScript      |
| Failed network requests         | `GET ... net::ERR_CONNECTION_REFUSED` | ❌ No                | Chrome network layer |
| CORS errors                     | `Blocked by CORS policy`              | ❌ No                | Chrome security      |
| Mixed content / cookie warnings | `Cookie “X” rejected`                 | ❌ No                | Browser security     |
| Deprecation warnings            | `[Deprecation] ...`                   | ❌ No                | Browser runtime      |
| CSS or layout warnings          | `Error parsing CSS...`                | ❌ No                | Renderer engine      |
| Extension messages              | `[AdBlock] ...`                       | ❌ No                | Chrome extensions    |

***

✅ **In short:**\
If you can find a log in DevTools that doesn’t show a filename/line number or says something like `[Deprecation]`, `[Intervention]`, or `net::ERR_...`,\
that message comes from the **browser**, not from your app — and Birdie cannot capture it.

</details>