> For the complete documentation index, see [llms.txt](https://docs.bugbug.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bugbug.io/debugging-tests/network-logs.md).
# Network logs
### Network Logs (HAR)
BugBug automatically captures network activity during every test run — both local and cloud. This lets you inspect HTTP requests, responses, status codes, and timing to diagnose failures caused by API errors, slow endpoints, or unexpected redirects.
***
#### How to access network logs
Network logs are available for every test run when they are enabled (by default) in Project Settings.
1. Go to the **Runs history**
2. Go to the failed test run and click **Details**
3. Click **Download network logs (HAR)** to download the file
> 💡 The download link is also available directly in the failed step when the test failed.
>
> 
***
#### What is a HAR file?
HAR (HTTP Archive) is a JSON-based standard that records all network requests made by the browser during a test. The file is compressed as a `.zip` archive containing a `.har` file inside.
Each entry in a HAR file includes:
* **URL** – the full request URL
* **Method** – GET, POST, PUT, etc.
* **Status code** – e.g. 200, 404, 500
* **Request & response headers**
* **Request body** (for POST/PUT requests)
* **Response body**
* **Timing** – how long each request took
***
#### How to open a HAR file
After downloading and unzipping the archive, you can open the `.har` file in several ways:
**Chrome DevTools**
1. Open Chrome DevTools → **Network** tab
2. Drag and drop the `.har` file into the Network panel
**Online viewers**
* [HAR Analyzer by Google](https://toolbox.googleapps.com/apps/har_analyzer/) — good for quick inspection
* [HAR Viewer](http://www.softwareishard.com/har/viewer/) — detailed timeline view
**Other tools**
* Firefox DevTools (Network tab → Import)
* Charles Proxy, Fiddler, Insomnia — for deeper analysis
***
#### Common debugging scenarios
**API returning an error**
Look for requests with status codes `4xx` or `5xx`. Check the response body for error messages from your backend.
**Test failing on page load**
Look for failed requests to JS bundles or critical API calls that happen right after navigation.
**Assertion failing unexpectedly**
Check if the data your test asserts against is fetched correctly — the response body will show what the server actually returned.
**Slow or timing-out steps**
Review the timing column to find requests that take unusually long and may be causing timeout failures.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.bugbug.io/debugging-tests/network-logs.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.