Trace and Troubleshoot a Web Request

Inspect a browser request, map its path, and troubleshoot simulated outages.

Introduction

30 Second Summary

When a website feels slow or stops loading, the browser already holds clues about where the problem happened. The challenge is turning those clues into evidence you can explain.

In this project, you will use Microsoft Edge DevTools to investigate one HTTP request from click to response. Your investigation becomes a visual network path in draw.io plus an outage-and-recovery record.

What You'll Build

You will show a real getstarted.json request moving from browser to server through a shareable diagram backed by captured timing evidence.

By the end of this project, you'll have:

A captured request trace that you can explain through its Status, Type, Time, Headers, Response, and Timing evidence.
An editable network path diagram that connects the browser to a DNS resolver before following the request through the network to the web server.
A completed troubleshooting record that distinguishes a connectivity outage from latency on a working path.
Secret Mission: Package the captured session as a sanitized HAR file that DevTools can reopen as portable evidence.

Are there any prerequisites?

You need only a Windows 10 or Windows 11 computer with internet access. Every tool runs free in the browser.

Before We Start

Before any browser tools come into view, this step locks in the request you will trace from client to server and back. You will also connect that investigation to the evidence-based troubleshooting expected in a network-engineering career.

Open Your Browser Networking Lab

Your investigation goal needs evidence from a real request. A controlled demo in Microsoft Edge gives every learner the same traffic to inspect.

DevTools records browser requests in a visible Network Log. draw.io gives that evidence a blank canvas for the path diagram you create later.

In this step, get ready to:

Open the official network tutorial in Microsoft Edge.
Populate the Network Log with requests from a page refresh.
Prepare a blank draw.io diagram for the network path.

Open the Edge network demo

The official demo produces predictable browser traffic. This gives your first Network Log a clear source.

Select the Start button on the Windows taskbar.
Type Microsoft Edge into the Start search.
Select Microsoft Edge from the search results.
Select the address bar at the top of Microsoft Edge.
Paste https://microsoftedge.github.io/Demos/network-tutorial/ into the address bar.
Press Enter to load the network tutorial.

You should see the network tutorial page. The page includes a Get Data control that you use in the next step.

Right-click an empty area of the tutorial page.
Select Inspect from the menu.
Select the Network tab in the DevTools Activity Bar.

You should see the Network tool beside the tutorial page. Its Network Log is ready to record the next page load.

What is the Network tool?

The Network tool turns downloaded resources into inspectable rows. Each row gives you evidence about one browser request.

Populate the Network Log

The Network Log records activity after the Network tool is open. Refreshing the page gives DevTools a complete page load to capture.

Confirm that the recording control in the Network toolbar is active.
Select the recording control once if it is inactive.
Select Refresh in the Microsoft Edge toolbar.

You should see the Network Log fill with request rows. Each requested resource gets its own row.

That first capture is working. Your browser is now feeding real request evidence into DevTools.

Is the Network Log empty?

An empty log usually means the Network tool started after the page finished loading.

Confirm that the recording control is active.
Refresh the network tutorial again.

Ask for help if the rows still do not appear: help me troubleshoot an empty Network Log in Microsoft Edge DevTools.

Prepare a blank network diagram

A network diagram translates browser evidence into a path you can explain. The blank canvas keeps this setup step focused on preparing your workspace.

Select the plus-shaped control beside the network tutorial tab to create a separate Edge tab.
Select the address bar in the new tab.
Paste https://app.diagrams.net/ into the address bar.
Press Enter to load the draw.io editor.

The editor may ask where you want to store your diagram. Device storage keeps the editable file on your computer.

Select Device if a storage choice appears.
Select Blank Diagram to create a new canvas.

You should see an empty draw.io canvas ready for the network path you create later.

Does the diagram editor fail to load?

Confirm that the address bar contains https://app.diagrams.net/.
Reload the draw.io tab after confirming your internet connection.

For more help, ask: help me troubleshoot why the draw.io editor is not loading in Microsoft Edge.

Before the final refresh, how many request rows do you expect one page load to create?

Switch back to the Microsoft Edge network tutorial tab.
Select Refresh in the Microsoft Edge toolbar.

You should see the Network Log display one row per requested resource. This confirms that recording is active for the official demo.

Return to the draw.io tab after completing the checks.

You should see the blank canvas waiting in its separate tab. Your browser networking lab is ready for the request capture.

Next, you will isolate one real request and inspect the evidence behind its response.

Capture and Inspect a Web Request

Your browser networking lab is ready. Microsoft Edge DevTools is already recording the resources loaded by the demo page.

A request list is raw traffic until you can explain the client-server communication behind one row. In this step, you will isolate getstarted.json and use its details to explain the work across the network.

In this step, get ready to:

Capture getstarted.json with its observed Status, Type, and Time.
Inspect the request details without recording sensitive data.
Relate each visible Timing phase to one stage of the network exchange.

Capture the Get Data request

A cleared Network Log isolates the action you are testing. This gives you a focused capture without earlier page traffic mixed into the evidence.

Switch back to the Microsoft Edge tab showing the official network tutorial.
Clear the Network Log using the clear control in the Network toolbar.
Click Get Data on the demo page.
Locate the new getstarted.json row in the Network Log.
Read the value in the Status column.
Read the value in the Type column.
Read the value in the Time column.
Keep the request row visible for your checkpoint.

You should see a new getstarted.json row with values in the Status, Type, and Time columns. Your first clean request capture is ready for investigation.

Can't find getstarted.json?

Confirm that the recording control is active.
Click Get Data once more.

Ask for help if the request still does not appear: help me find getstarted.json in the Microsoft Edge Network Log.

Inspect the request and response

The details pane turns the row into an HTTP exchange you can inspect. It separates request metadata from the content returned by the server.

Protect Browsing Data

Request details from authenticated sites can contain private session data. This cleared official demo keeps your investigation focused.

Select the getstarted.json request row.
Select the Headers tab in the request details pane.
Identify the requested URL shown in the request details.
Read the request headers for the selected request.
Read the response headers for the selected request.
Select the Response tab.
Identify the content returned by the server.
Leave unrelated cookies or authorization values out of your notes.

You should now be able to identify what the client requested. You should also see the content that the server returned.

What Do Headers and Response Show?

Headers describe metadata attached to the request or response. The Response view shows the returned content itself.

Together, these views show what crossed the client-server boundary. They give you evidence for both sides of the exchange.

Explain the timing phases

Timing turns the exchange into a sequence. It shows where the browser spent time before the response finished.

Before you select Timing, which stages do you expect a browser request to reveal?

Select the Timing tab for getstarted.json.

You should see the phases that Edge needed for this request. The visible phases form the request's network timeline.

What Do the Timing Phases Mean?

DNS Lookup represents name resolution through DNS.
Initial connection represents transport setup through TCP. It can also include TLS work for a secure site.
Request sent represents transmission of the request to the server.
Waiting (TTFB) represents the wait until the first response byte arrives.
Content Download represents transfer of the response content to the browser.

Your timeline may omit some phases. Edge may have reused an existing connection.

Record every visible Timing phase in your final checkpoint below.

The selected getstarted.json row should expose Headers, Response, and Timing evidence. Your notes should contain only observations from this cleared demo session.

You have turned one row of traffic into evidence you can explain. Next, you will map that evidence into a network path diagram.

Diagram the Network Path

You have already turned one browser request into timing evidence. Those isolated labels still hide the end-to-end path that a network engineer needs to explain.

A network path diagram turns that evidence into a mental model. You will build one in draw.io from the browser evidence you already collected.

In this step, get ready to:

Build five labeled network nodes using draw.io's Networking shapes.
Map the observed request stages across a complete round trip.
Produce both an editable .drawio file plus a shareable PNG.

Build the five path nodes

A node represents one point in the request path. The five nodes give your timing observations a concrete route from the browser to the server.

Switch back to the draw.io tab from earlier.
Select More Shapes at the bottom of the shapes panel.
Scroll to Networking.
Enable at least one shape library under Networking.
Select Apply.
Add five network shapes to the blank canvas.
Label the shapes Browser, DNS Resolver, Home Router or ISP Edge, Internet, plus Web Server.
Arrange the five shapes from left to right in that order.

You should see five labeled points stretching across the canvas. Their order provides the backbone for the complete request path.

Can't find the network shapes?

Reopen More Shapes if the shapes panel still contains only basic shapes.
Scroll down to the Networking section before selecting a library.

If the libraries still do not appear, help me find the network shapes in draw.io.

Connect the request round trip

A conceptual path links each observed timing phase to part of the browser-to-server journey. It keeps the diagram grounded in evidence without claiming knowledge of every physical network hop.

Connect the nodes in this order: Browser, DNS Resolver, Home Router or ISP Edge, Internet, followed by Web Server.
Set the connector arrows to show the forward direction from Browser toward Web Server.
Add the DNS Lookup label near the connection between Browser plus DNS Resolver.
Add the Initial connection label along the path toward Internet plus Web Server.
Add the Request sent label to the final forward flow into Web Server.
Add a return connector from Web Server back to Browser.
Add the Waiting (TTFB) label near the server end of the return connector.
Add the Content Download label along the remaining return flow.

The diagram now shows the request moving toward the server. A separate connector shows the response returning to the browser.

Add a note beneath the diagram that reads Conceptual path based on browser evidence. Physical route discovery is outside this diagram's scope..

Why is the path conceptual?

Browser timing evidence identifies stages such as name resolution, connection setup, request transmission, waiting time, plus content transfer. It does not reveal every router or physical link used across the Internet.

The scope note keeps your conclusion aligned with the evidence. Physical route discovery would require additional network tools.

Save and export the diagram

An editable .drawio file preserves the shapes for later updates. A PNG gives you a fixed image that is easy to open or share.

The storage choice can feel fiddly because draw.io supports several destinations. Device keeps the files on your computer.

Select File in the draw.io menu bar.
Select Save As.
Choose Device as the storage location.
Enter web-request-path.drawio as the filename.
Choose your default download folder if the browser asks for a location.
Confirm the save.

You should see browser confirmation that web-request-path.drawio finished downloading.

Why keep both files?

The web-request-path.drawio file retains the editable shapes, connectors, labels, plus notes.

The exported PNG includes a copy of the diagram data when the embedding option stays selected. That copy provides another route back to editable content.

Select File in the draw.io menu bar.
Select Export As.
Select PNG.
Keep Include a copy of my diagram selected.
Select Export.
Name the exported file web-request-path.png.
Choose your default download folder if the browser asks for a location.

Before you open the export, can you picture where the forward request becomes the returning response?

Select the downloads button in the Microsoft Edge toolbar.
Confirm that web-request-path.drawio plus web-request-path.png appear in the completed downloads.
Open web-request-path.png from the completed downloads.

You should see five connected nodes in order. The request-stage labels should follow the forward path.

The response-stage labels should follow the return path. The conceptual-evidence note should remain readable beneath the diagram.

That's the full request turned into a troubleshooting artifact you can explain. Your browser observations now have a visual path from client to server plus the returning response.

Does the PNG look incomplete?

Return to the draw.io tab from earlier.
Move every shape inside the visible page boundary.
Check that each connector reaches the intended node.
Repeat the PNG export with Include a copy of my diagram selected.

If the export still cuts off part of the path, help me fix my incomplete draw.io PNG export.

Your captured request now has an editable visual explanation plus a shareable export. Next, you will create a controlled outage to see how a connectivity failure changes the evidence.

Create and Observe an Outage

Your successful getstarted.json request in Microsoft Edge DevTools gives you a baseline for normal browser-to-server traffic. The recorded status, response, and timing show what working connectivity looks like.

A baseline becomes useful in troubleshooting when you compare it with controlled failure evidence. In this step, you will simulate a missing data connection and document the failed fresh reload.

In this step, get ready to:

Simulate an offline connection with the browser cache disabled.
Observe the failed fresh reload in the Network Log.
Document the outage in your draw.io diagram.

Simulate an offline connection

A browser cache can reuse content stored by an earlier successful visit. Disabling it makes the next reload depend on current network access.

Switch back to the Microsoft Edge tutorial tab from earlier.
Select Disable cache in the Network toolbar.
Open the No throttling menu.
Select Presets.
Select Offline.
Clear the Network Log using the clear control in the Network toolbar.

You should see Offline displayed in the throttling menu. The empty Network Log gives the next reload a clean evidence window.

Why clear the Network Log?

The previous rows belong to your successful baseline. Clearing them isolates the requests created by this offline test.

Observe the failed reload

Before you reload, which parts of your successful baseline do you expect the fresh attempt to preserve?

Reload the Microsoft Edge network tutorial page.

You will see that the page cannot complete a fresh network load. This shortfall is intentional.

Inspect the request rows created by the attempted reload.
Select an attempted request row if Edge lists one.
Check the Status information.
Select the Response tab.
Select the Timing tab.

What does the missing evidence show?

You should find no successful HTTP status or normal response body. Normal successful timing evidence is missing too.

This combination shows that the browser did not complete a successful exchange with the server. The evidence points to a client-to-network connectivity failure.

Does the reload still look successful?

Confirm that Disable cache remains selected.
Confirm that the throttling menu displays Offline.
Clear the Network Log before repeating the reload.

Ask for help with the test if the request still appears successful: help me troubleshoot why my Edge Offline test still shows a successful request

Document the outage in your diagram

A useful troubleshooting record connects the symptom to the test condition. It also preserves the evidence that supports your conclusion.

Switch back to the draw.io tab from earlier.
Add a text note beside the conceptual network path.
Title the note Outage Observation.
Write the symptom as the failed fresh page reload.
Write the test condition as cache disabled with Offline active.
Write the evidence as the missing successful status, normal response body, and normal successful timing information.
Write the conclusion as a client-to-network connectivity failure.

You should now see an Outage Observation note beside the Browser-to-Web Server path. Each part of the note connects your conclusion to visible browser evidence.

Select File in the draw.io menu bar.
Select Save As.
Select Device if a storage choice appears.
Save the updated diagram as web-request-path.drawio.
Replace the existing file if your browser asks for confirmation.

You have turned a failed reload into a troubleshooting artifact that another person can follow. Your editable diagram now preserves the symptom, test, evidence, and conclusion.

Keep the baseline PNG

The existing web-request-path.png preserves the network path from before the outage note. This step updates only web-request-path.drawio.

Before your final check, which two controls should prove that the lab remains in its broken state?

Switch back to the Microsoft Edge tutorial tab from earlier.
Confirm that Disable cache remains selected.
Confirm that the throttling menu still displays Offline.

The Network Log should still contain no successful response for the attempted fresh reload. Edge remains in Offline mode for the recovery test in the next step.

Your outage evidence is captured in both DevTools and the editable diagram. Next, you will restore connectivity and compare this hard failure with a slow connection.

Restore Connectivity and Compare Speed

Your Offline test gave you a clear failure state in Microsoft Edge DevTools. A fresh load could not produce a successful HTTP response.

Now you will restore the request path before testing it under 3G throttling. Comparing both conditions turns latency into evidence that separates a hard outage from a slow connection.

In this step, get ready to:

Restore normal connectivity under No throttling.
Compare a 3G load with the recovered baseline.
Add all three network conditions to the final PNG troubleshooting diagram.

Restore the successful request

The Offline result is your known failure state. Changing only the throttling condition lets you connect the next successful response to restored connectivity.

Before you restore the connection, do you expect the same request to return successfully?

Keep Disable cache selected in the Network tool.
Select No throttling from the throttling menu.
Clear the Network Log.
Reload the Edge network tutorial page.
Click Get Data on the demo page.

You'll see a new getstarted.json row in the Network Log. The request now completes successfully.

Select the new getstarted.json row.
Record the value in the Status column as your recovery Status value.
Record the value in the Type column as your recovery Type value.
Record the value in the Time column as your normal Time value.
Select the Headers tab.
Select the Response tab.

You'll see inspectable request details in Headers. You'll also see returned content in Response.

You have recovered the path. The same client can reach the server again under No throttling.

No Recovery Request?

Confirm that No throttling remains selected.
Clear the Network Log again.
Reload the demo page.
Click Get Data again.

Ask for help if the request still does not recover: help me troubleshoot the recovery test.

Compare the recovered baseline with 3G

Offline removed the successful response path. The 3G preset keeps the path available while increasing the time needed to load resources.

Select 3G from the Throttling menu.

You'll see a warning icon while throttling is active.

Before you force a fresh load, do you expect the path to fail or complete more slowly?

Right-click or long-press Reload.
Select Empty cache and hard refresh.

You'll see the page complete its load after a longer wait. The Network Log still contains successful request rows.

Record a slower value from the Time column as your 3G Time value.
Compare your 3G Time value with your normal Time value.
Return the throttling menu to No throttling.

You'll see the throttling warning icon disappear. Your browser lab is back at its normal baseline.

You now have a clear diagnosis. Offline removes the successful response path. 3G preserves the path with extra delay.

Does the 3G Load Look Unchanged?

Keep 3G selected until the refreshed page finishes loading.
Repeat Empty cache and hard refresh while 3G is active.
Compare the new Time observation with your No throttling value.

Ask for help if the timing still looks unchanged: help me verify the 3G test.

Finish the troubleshooting diagram

Your existing draw.io tab contains the request path plus the Outage Observation note. The final summary connects that failure to the recovered baseline and the slower 3G test.

Switch back to the draw.io tab from earlier.
Add a Troubleshooting Summary heading in an open area of the diagram.
Add the line Offline: no successful network response.

The first summary line now connects the failed reload to the missing network response.

Add the line 3G: the path still works but takes longer.
Add the line No throttling: baseline restored.

You'll see the normal condition beside the Offline outage and the slower 3G observation.

Select File in draw.io.
Select Save As.
Select Device if a storage choice appears.
Save the editable diagram as web-request-path.drawio.
Confirm replacement if your browser warns that the file already exists.

Your editable diagram now preserves the complete troubleshooting summary.

Select File again.
Select Export As.
Select PNG.
Keep Include a copy of my diagram selected.
Select Export.
Save the final image as web-request-path.png.

Before you open the final export, which three network conditions do you expect the image to preserve?

Open web-request-path.png from the folder where you saved it.

You'll see the connected Browser-to-Web Server path with normal, Offline, and 3G observations. You'll also see the troubleshooting summary that distinguishes each condition.

That completes your investigation artifact. The final PNG shows a failed path, a slower functioning path, and the restored baseline.

Latest Changes Missing From the PNG?

Return to the draw.io tab from earlier.
Confirm that the troubleshooting summary is visible on the canvas.
Save web-request-path.drawio again.
Repeat the PNG export with Include a copy of my diagram selected.

Ask for help if the export still shows an older version: help me fix the draw.io export.

Secret mission

Package the Evidence as a Sanitized HAR

The live Network Log is temporary. Package the successful request as a sanitized HAR. Reopen the file to prove the evidence can travel without rerunning the page.

Clean Up Your Resources

This browser-only project has no ongoing costs. Choose whether to keep your evidence, pause your browser work for later, or delete the saved files.

Resources you used:

The sanitized HAR capture saved as sanitized-network-session.har.
The editable draw.io diagram saved as web-request-path.drawio.
The final PNG diagram saved as web-request-path.png.

Keep everything running

No action needed. This option keeps your captured session with both versions of the network path diagram.

Keep sanitized-network-session.har so you can reopen the captured session in Microsoft Edge DevTools.
Keep web-request-path.drawio so you can update the network path or troubleshooting notes.
Keep web-request-path.png so you can share the finished diagram without opening the editor.

Pause - I'll come back to this later

No services run in the background. This option ends the active browser session while preserving your evidence.

Close Microsoft Edge when you finish reviewing the imported HAR.
Leave sanitized-network-session.har on your device for future request analysis.
Leave web-request-path.drawio on your device for future diagram edits.
Leave web-request-path.png on your device as the finished visual record.

Delete - I don't want to use this again

Deleting the saved evidence can feel final. Microsoft Edge and the official demo remain available after you remove the three local files.

In Microsoft Edge, open the browser's downloads list.
Use the sanitized-network-session.har entry to open its saved folder.
Delete sanitized-network-session.har from that folder.
Use the web-request-path.drawio entry to open its saved folder.
Delete web-request-path.drawio from that folder.
Use the web-request-path.png entry to open its saved folder.
Delete web-request-path.png from that folder.

Nice Work!

You did it! Your completed investigation traces a real browser request across its full client-to-server round trip.

What you learned:

Built a set of request evidence by capturing getstarted.json in Microsoft Edge DevTools. Used its recorded details to explain what the client requested. Used its response details to explain what the server returned. Connected its timing phases to the work performed across the network.
Created an editable network path diagram in draw.io. Mapped browser evidence to DNS resolution. Mapped the same evidence to connection setup. Extended the path through HTTP transmission to response delivery.
Reproduced an Offline outage in DevTools. Restored the No throttling baseline. Compared that recovery with a functioning but slower 3G link.
Completed the optional Secret Mission. Exported a sanitized HAR file. Reopened the saved session in DevTools as portable troubleshooting evidence.

Ready to quiz yourself?