Copy as cURL, Paste, Repro: The Fastest Debug Loop Using Mockfill

The most expensive sentence in a bug ticket is "I can't reproduce this locally." Once you say it, the bug enters a different category — guess-and-check, log-spelunking, hours of overhead — even if the actual fix is two lines.

Most of the time, the bug is not non-deterministic. It depends on a specific API response: a particular field being null, a particular status code, a particular ordering. The reason you cannot reproduce it locally is that your local backend never returns that exact response. If you can freeze the response, you can freeze the bug.

Nano Banana prompt: "Flat vector illustration of a stylized network request packet (depicted as a glowing JSON brace icon) being frozen mid-flight by a sci-fi 'freeze ray' device labeled 'Mockfill'. To the right, a small replay icon shows the same packet being repeatedly fired into a browser window. Indigo and cyan palette, soft shadows, dotted grid background. Caption: 'Freeze the network, freeze the bug.'"

The five-minute repro loop

1. Reproduce the bug once. Anywhere — staging, prod, the user's session shared via screen recording. You only need it to happen one time.
2. Open DevTools → Network. Find the offending request.
3. Copy as cURL. Right-click → Copy → Copy as cURL.
4. Capture the response. Click the request, go to Response tab, copy the body.
5. Paste into Mockfill. Import the cURL (URL and method auto-fill), paste the response body, set the status and any relevant headers.

Reload your local app. The bug now happens on demand, every time, in a debugger you control.

Nano Banana prompt: "Annotated UI mockup of Chrome DevTools Network panel showing a list of requests. A right-click context menu is open with 'Copy → Copy as cURL' highlighted in cyan. A curved arrow points from the menu item across to a Mockfill extension panel on the right with a 'Paste cURL here' textarea glowing. Caption: 'Two clicks from prod failure to local reproduction.' Light theme, modern flat design, indigo accents."

A real example

A user reports that the invoice list page crashes when they paginate. You cannot reproduce it locally because your seed data only has three invoices.

You ask the user to reproduce it on a screen share. The failing request is:

curl 'https://app.example.com/api/invoices?cursor=eyJpZCI6ImludjI3In0' \
  -H 'accept: application/json' \
  -H 'authorization: Bearer <redacted>'

The response body has 47 invoices and one of them has amount: null — which is the bug. You import the cURL into Mockfill, paste the response, and reload your local app. The crash happens immediately. Now you can attach the debugger, find the line that does invoice.amount.toFixed(2) on a null, and ship the fix.

What used to be a three-hour debugging session is a ten-minute one. Most of the saving is in the part where you no longer have to guess what the data looked like.

Why this beats console logs and Sentry breadcrumbs

Logging frameworks tell you what happened. They do not give you a system you can poke at. The instant you have the response frozen as a Mockfill rule, you can:

• Add a breakpoint and step through.
• Edit the response body to test fixes ("does it still crash if amount is 0?").
• Test edge variants ("what if there are 1000 invoices?") by mutating the body.
• Hand the rule to a teammate as a JSON file and have them reproduce the same bug in 30 seconds.

Sentry tells you the bug exists. Mockfill lets you hold it.

Nano Banana prompt: "Split-screen UI mockup. Left: a code editor with a debugger paused on a highlighted line 'invoice.amount.toFixed(2)' with a red breakpoint dot and call stack visible. Right: a Mockfill rule panel showing the captured response body containing an invoice with 'amount: null'. A glowing line connects the null in the JSON to the crashing code line. Caption: 'The bug is now a thing you can step through.' Dark editor theme on the left, light theme on the right, indigo accents."

Sharing the repro

Mockfill exports rules as JSON. Attach the JSON to the bug ticket:

INV-2847.json   ← drop this into Mockfill, hit reload, see the bug

This is the single most effective bug-reporting upgrade a frontend team can make. The "steps to reproduce" section becomes one line: "Import the attached JSON and reload the invoices page."

Be careful with sensitive data

Real API responses contain real user data. Before saving a cURL or response into a shared repo, redact:

• Auth tokens in authorization headers
• PII in the response body (emails, names, account IDs if they identify real users)
• Internal-only headers your backend may add

A two-minute redaction pass is the price of a shareable repro. Build a small habit around it.

When the bug is not in the response

Sometimes the response is a red herring and the bug is in timing, ordering, or state. Mockfill helps here too — add a delay to the rule to test race conditions, or create multiple rules for the same endpoint and toggle between them mid-session to test "what if the second call returns differently from the first."

Graduating the repro into a regression test

Once you fix the bug, the response that triggered it is the most valuable test fixture you have. Port it into a Cypress cy.intercept or Playwright route.fulfill and add an assertion that the page does not crash. The same JSON that reproduced the bug becomes the test that prevents its return.

The takeaway

"I can't reproduce it locally" is almost always a euphemism for "I don't have the right response body." Mockfill's cURL import gives you the body. Everything downstream — the fix, the test, the closing comment on the ticket — gets cheaper.