Playwright Network Errors: Tell an HTTP Failure from a Failed Request

Start with the kind of failure

A report button can produce an error even when the browser successfully contacted the server. In Playwright, an HTTP 404 or 503 is a response, and that status alone does not cause a requestfailed event. A request can still fail after response headers arrive if the response body cannot be downloaded; a connection problem or abort can also prevent a usable response altogether. The request event documentation describes both paths, and the network guide explains monitoring requests and responses.

That distinction changes the next step. For an HTTP response, inspect the status and the endpoint's documented error handling. For a failed request, look for a network or browser error and the request that failed. For either, preserve the application's visible error state and avoid retrying an operation that might have side effects until you understand its contract.

Wait for the relevant response

This example assumes an owned fixture where “Load report” sends GET /api/report, a 200 response means the report is available, and a separate status element becomes “Ready.” It attaches the expectation before clicking, so a fast response isn't missed.

from playwright.sync_api import expect

def load_report(page):
    with page.expect_response(
        lambda r: r.url.endswith("/api/report")
        and r.request.method == "GET",
        timeout=3000,
    ) as pending:
        page.get_by_role("button", name="Load report").click()
    response = pending.value
    if response.status != 200:
        raise RuntimeError(f"Report request returned HTTP {response.status}")
    expect(page.get_by_test_id("report-state")).to_have_text("Ready")

The exact function was exercised with local synthetic 200 and 503 responses and a locally aborted request. It wasn't tested against a provider or a customer account. Adapt the URL predicate, method, status and timeout to the endpoint's contract. If several concurrent requests have the same URL and method, add a stable distinguishing property rather than assuming the first response belongs to your click.

Don't filter away the error you need

The predicate above identifies the request without requiring status 200. If it also required r.status == 200, a 503 would never match and the test could report only a timeout. Once the response is captured, check its status explicitly. Playwright's response expectation supports a URL or a predicate.

A 200 still doesn't prove the report was rendered or saved. A server can return a login page or a valid response that contains an application-level error. Check the expected content type or result according to the service contract, then assert the user-visible outcome. For an asynchronous 202 job, wait for its documented completion state instead of treating acceptance as completion.

When no response arrives

Register a requestfailed listener before the action when diagnosing a controlled test. It can tell you which request failed, while the response expectation may time out because no response matched. Don't dump raw URLs with query strings, headers or request bodies into shared logs: they can contain credentials or customer data. Record a redacted endpoint, error category and time instead.

Redirects need their own inspection. Playwright documents that a redirect response completes one request and starts another; a redirect to a sign-in page may leave the browser on a page that looks successful while the intended report is unavailable. Check the final page and authentication state, not just one intermediate status. A 401, 403 or access challenge is a reason to stop and contact the owner, not a cue to loop around the restriction.

Use a local fixture to exercise a 200 result, an HTTP error and a failed request before running an authorized job. If you need help diagnosing a workflow, ask for a scoped assessment with a redacted reproduction and the expected outcome.