Cloudflare's New Session Inspector: A Beginner's AI Debugging Checklist

You click a button. The screen stays empty. You tell your AI coding tool, "The button is broken. Fix it."

That sentence describes your frustration. It barely describes the failure.

The click might never reach the intended control. The app might send the wrong request. The server might return an error. Or the server might return exactly the right data and the page might fail while displaying it.

Those problems can look identical in a screenshot. They need different repairs.

On September 18, 2026, Cloudflare added an Inspect panel to Browser Run Session Recordings. It puts console logs, network activity, and a view of the page's final DOM structure alongside the recording. The network view includes request details, responses, and timing; the DOM is the browser's structured representation of the page.

That is useful because a replay can show the symptom while the surrounding evidence helps you locate where the behavior went wrong.

My takeaway for beginners is practical: give AI a connected account of the failure before asking it to repair anything.

1. Write the expected result before collecting evidence

Imagine a small reading-list app. This is a hypothetical example, not a client incident.

You have one unread article saved. You choose the Unread filter. You expect that article to remain visible. Instead, the list goes blank.

I would write the bug this way:

"In the test account with one unread article, selecting Unread shows an empty list. Expected: the saved article remains visible. Starting from All, this happens on each of three attempts."

That gives us a starting state, an action, an expectation, and an observation. "Filters are broken" gives us a guessing contest.

If you want a guided way to organize your first build and its debugging questions, my $1 AI App Builder Starter Prompts are a practical starting point. Use the checklist here to supply the evidence when a debugging prompt needs more than a description.

2. Keep evidence from the same run together

I would record the app version, browser, relevant test data, and exact steps. Then I would reproduce the failure once with the appropriate capture enabled.

Mixing a screenshot from yesterday with today's console error can create a persuasive story about two different bugs.

For the reading-list example, the useful sequence is:

1. The test account begins with one unread article under All.
2. I select Unread.
3. The browser sends the filter request, if this app fetches filtered results from the server.
4. The response arrives, or fails to arrive.
5. The page updates, or reports an error.

Some apps filter locally and should send no request. Establish the expected design first. An absent request is evidence only when a request should exist and your capture was active.

Playwright's Trace Viewer illustrates this approach for automated tests: it connects actions with snapshots, logs, and network activity, and lets you narrow inspection to an action's time range. You can apply the same reasoning manually with the browser's developer tools. You do not need to move your app to Cloudflare to use the lesson.

3. Find the first point where reality disagrees

I would ask AI to walk through the sequence and separate observations from explanations.

Suppose our fictional recording shows the correct filter request, a successful response containing the unread article, and then a JavaScript error while the page renders the list.

That points the next investigation toward the response-to-screen path. It does not prove the exact broken line. It also gives us little reason to start by rewriting the server's filter logic.

Different evidence would change the next step:

• If the selected filter never changes, inspect the click target and event handling.
• If the filter changes but the request asks for read articles, inspect how the selection becomes request parameters.
• If the request is correct but the response is unexpected, inspect the relevant server behavior and test data.
• If the response contains the expected article but the page stays blank, inspect how the app reads and displays that response.

These are investigation paths, not automatic diagnoses. A successful HTTP status alone does not establish that the returned content is correct.

The question I care about is: where is the earliest observable mismatch we can actually demonstrate?

4. Ask for a discriminating check, not five speculative patches

For our blank list, imagine two plausible explanations: the display code expects the wrong response shape, or a second request arrives later and replaces the correct result.

I would ask for one check that distinguishes them. For example, inspect the response handling and the order of state updates in a disposable local reproduction. A narrowly placed diagnostic log might be enough; another recording might be necessary.

If AI proposes changing the filter, increasing a timeout, clearing the cache, and rewriting the component together, we lose the ability to tell which explanation survived contact with evidence.

Here is the prompt I would use:

"Read this bug report and the sanitized evidence from the same run. Separate confirmed observations from hypotheses. Find the earliest mismatch with the expected behavior. Give me the two most plausible causes and the smallest safe check that would distinguish them. Explain what each possible result would mean. Do not change code yet."

Once the evidence supports a cause, make the smallest coherent repair. Repeat the original failing sequence and one nearby case that should still work. For the reading list, that might mean Unread shows the unread article while Read correctly shows an empty state.

5. Check what the recording cannot tell you

Cloudflare's session-recording documentation describes a reconstruction from page structure and events, rather than a video. Recording must be enabled when acquiring the session. The documentation also lists gaps, including canvas content and cross-origin frames; input values are masked in the replay by default.

That matters when you interpret a blank region or missing value. The capture might be incomplete even when the app behaved correctly.

A final page snapshot also cannot establish every earlier state. And a browser trace does not automatically reveal everything a server did internally.

I would put missing evidence in the bug report explicitly: "Server-side processing was not captured" is more useful than an invented explanation.

For an intermittent bug, record how often it happens and under which conditions. A successful rerun does not erase the failed run. It gives you another observation to compare.

6. Share the smallest safe evidence package

More captured data creates more material to inspect and more opportunities to expose something private.

I would use a test account with synthetic records whenever possible. Keep the relevant time range and error details, and remove unrelated customer content before sharing anything with an AI service or a public issue tracker.

Chrome's network documentation says its sanitized HAR export excludes sensitive headers such as Cookie, Set-Cookie, and Authorization. A HAR is a file containing recorded network activity. I would still inspect the material I intend to share: removing those headers does not establish that every URL, payload, response, or screenshot is appropriate for disclosure.

For many beginner bugs, a short report and a carefully chosen error excerpt are enough. A giant archive is useful only if it answers a question the smaller report cannot.

The bug-report template I would keep in my project

Before asking AI for a repair, fill in these seven lines:

• Expected result: what the user should accomplish.
• Starting state: app version, browser, test account role, and relevant synthetic data.
• Reproduction: the shortest reliable sequence of actions.
• Actual result: what happened, including how often it happened.
• Evidence: matching screenshots, errors, and relevant request/response observations from that run.
• Known gaps: what was not captured or could not be reproduced.
• Next question: the smallest uncertainty we need to resolve before editing code.

My job as the builder is to make the failure inspectable. AI can help connect the evidence, propose explanations, and implement a repair. I still want the explanation to earn the code change.

Start with the $1 AI App Builder Starter Prompts for guided action toward a stable first build. For the organized path from idea to publication, the $9 AI App Builder From Zero e-book connects planning, architecture, building, QA, and launch. All 40 Starter Prompts are included as a free bonus inside its PDF and EPUB.

Review Radar is coming soon. Its planned package combines app-market research, tailored screens, and an AI-ready project folder to give your build a concrete starting plan. View the preview and join the email waitlist. Checkout is not open, and the package does not promise a finished app or revenue.

You can also find me here:

Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/
Upwork: https://www.upwork.com/freelancers/marcusykim