Seamless Digital Experience.
Happy Customers.

Digital Experience and Error Monitoring Platform - Zipy

How Zipy debugs issues in the network layer effectively?

Amit Pareek
~ 3 mins min read | Published on Mar 06, 2024


Fix bugs faster with Zipy!

  • Session replay
  • Network calls
  • Console Logs
  • Stack traces
  • User identification
Get Started for Free

As a developer myself, the most complicated part of the job is not writing the code but reproducing an issue the customer reported, debugging, and fixing the issue. With such little information at your disposal, it becomes a nightmare to start debugging the issue, let alone fixing it. Can we do something better here?

Well, that is when Zipy comes into the picture. It lets you easily view the issues that have occurred in the customer's environment and provides you with many insights that can help you significantly reduce the time to fix a bug. One such feature is the Network section in the dev tools that can quickly help us detect if there is any issue in the Network event.

The Problem

Out of the blue, a customer reports an issue where they are facing a problem with a particular flow. And you, have no clue how did this error occur. Is it an API request failure? Is there an issue in customer environment? Or is it the browser cache? Debugging such an issue can become a challenge.

The Solution

Use of network logs in Zipy. You can view the network event by clicking on the Open in Dev Tools link in the breadcrumbs of the session replay. That opens a new section right below the session replay where you can view the Network events, Console logs, and Stack traces. Our area of interest for this blog is the network tab which has the details of all the Network calls in the session like Headers, Timestamp, Status, Type, and URL.

Identifying network events in the breadcrumbs

In the headers section, you can view all the types of Headers of the API call like Request, Response, and General Headers. The request header parameters are pretty handy to debug issues related to the APIs invoked from the client-side. For instance, the following screenshot request-id header is the one that will be available in the backend logs. We can use the request-id that is unique for a particular user, to search logs in the Log search engine like Splunk, CloudWatch, Elastic Search, or any of your log servers.

search logs in the search engine with help of request

Zipy does not capture the request payload by default. However, please contact our support team to enable such a setting if you need the payload information. For example, if you log some custom parameters from the request payload, you can reference the network payload events to track the logs.


Using Zipy’s user session replay along with the additional information in the breadcrumbs/network tab can give developers the most critical information they need to analyze issues that the customers have reported. Using API headers can be pretty powerful to search the logs in the backend effectively. It can reduce time and effort and provide some interesting insights to help resolve issues and even proactively fix bugs. With Zipy you can Save 50% of developer time by solving tough customer bugs.

Call to Action

Feel free to comment or write to us in case you have any further questions at We would be happy to help you. In case you want to explore for your app, you can sign up or book a demo.

Fix bugs faster with Zipy!

Get Started for Free
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Want to solve customer bugs even before they're reported?

The unified digital experience platform to drive growth with Product Analytics, Error Tracking, and Session Replay in one.

SOC 2 Type 2
Zipy is GDPR and SOC2 Type II Compliant
© 2023 Zipy Inc. | All rights reserved
by folks just like you
// open links in new tab script