How Zipy debugs issues in the network layer effectively?

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.

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.

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.

Conclusion

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.