Bridge the Knowledge Gap, Debugging 2 - Network Monitoring and Server Logs

5 minute read

Part Two of the Bridge the Knowledge Gap Series on Debugging
Check out Part One here

Learning syntax is only a small part of being a developer. The transition from coding bootcamp or online tutorials to the Real World can be a struggle. The objective of this series of blog posts is to summarize the knowledge that I gained during my own transition period (and beyond), and pay it forward to those that find themselves in a similar position.


A reminder of the debugging topics that we will be covering:

  1. “Look under the hood” - Print & interactive debugging

  2. “Tap the phone line” - Network monitoring & server logs

  3. General tips

Part Two: Tap the phone line

Browser Developer Tools

As web developers, testing features in the browser as we write code is a fairly standard practice in our typical development flow. Usually, when things aren’t working properly, we would expect to see some kind of error in the browser or Javascript console. However, oftentimes, we would be faced with an unresponsive UI or a blank screen.

Something that’s really useful in these cases is built right into the browser. If we open up the developer tools, we can see all these tabs. The most useful ones, from left to right, are Elements (HTML & styling), Console (Javascript) and Network (server activities).

Screencap of puppy app with the developer tools open and Elements, Console and Network highlighted

In the Network tab, lives a log of our network activities. It shows us whether our app’s resources are being downloaded or uploaded correctly, and the status of our application’s trips to and from the server.

When we first open up the dev tools, we won’t see anything in the logs yet. But once the tab is open, we can reload the page or repeat the action that was problematic and watch the logs populate with all the network activities.

Network tab with a 500 status request

Each row in the table at the bottom represents an HTTP request and the column gives you more information about each of the requests. The ones that I look at most often are the name of the resources, the status, which is the HTTP response code, and the resource type.

Some lines will appear in red if there are bad requests, maybe a 500 internal server error or a 403 forbidden.

When we click into one of these lines, we have access to more details like the request and response headers, and the response body. These sections will let us look at the requests more closely. I typically check to make sure the requests are going out to server with all the information that the backend needs to properly process the request.

In the Headers tab under an individual request line, there’s a request payload section that will tell us what information went out to the server, and we can see whether it’s behaving as expected or identify where it’s not.

Response tab in Network that shows a 500 returned from the server

On the flipside, there’s a Response tab that will show us what came back from the server as a result of our request.

Response tab in Network that shows a 500 returned from the server

In this case, it looks like our request resulted in a 500 internal server error, because it raised an ArgumentError on the backend because we gave some method the wrong number of arguments.

Server Logs

We can also look for similar information from the server-side by peeking into the server logs.

This is the place our backend will log information about each request coming in, how the server resolves the requests and the result. This is where exception and warnings will show up and where the Pry session will open if the program hits a breakpoint.

We have here the Rails server for Puppygotchi, the example app from Part One: Look Under the Hood. This is all the information the server logged during for the same action from when we saw the network logs in the browser.

Like with the network tab, we can see the HTTP request and which route it hits (Box 1), the response status code (Box 2), and the exception that was raised (Box 3), which we saw in the browser returns as part of the response body.

Rails server that logs the route a request hits, the response code and any exception or error raised


There are a lot of more advanced ways to read both the Network tab and the server logs, and get them to even better clues on how to approach our bugs. When I was first getting started, I had a hard time even remembering to look in these places; let alone knowing what it was telling me. This is only meant to point out something that’s easy to overlook:

Even though a bug manifests itself on the frontend doesn’t necessarily mean it’s something wrong with the frontend code.

I wasted a lot of time looking in all the wrong places only to realize that it was actually a backend issue disguising itself as a frontend error.

Captain Marvel drops through the ceiling of a bus to beat up an old lady

I also recommend keep an eye on the Network tab and the server logs as a matter of practice, because it is really beneficial to be familiar with how our programs. As we can saw, the logs don’t always tell us when something is misbehaving; they mostly just tell us what is happening. The output definitely are not always color-coded, so if we know what the logs look like when it’s correct, we will be able to spot when it’s not.

Be patient. The more we read these logs and error messages, the easier it would be next time to spot the important things.

CodeNewbie, Debugging, Ruby On Rails, Early career