"It's Not Working" Is Not an Error

Three weeks ago, the frontend developer on a team I manage reported an error she was facing:

"It's not working!"

Two days ago, another developer at work reported an error:

"500 Internal Server Error..."

No screenshot. No error message. No endpoint. No timestamp.
Just four words can mean anything, like a user forgetting to click "Save."

I've worked across multiple projects as a backend engineer, and I currently lead the build team behind FUTO Aid, our flagship student fundraising platform at IDC-FUTO. Leading a cross-functional team means I spend almost every day at the intersection of frontend and backend development.

One recurring friction point I've noticed is that frontend developers, who understand how software systems work, often report bugs the way end users do.

It isn't necessarily because they don't know better. More often, no one has shown them what good error reporting looks like or why it matters.

This article isn't a rant. It's the guide I wish existed the first time I sat down with a teammate and said, "I can't fix what I can't see."

Why Does Proper Error Reporting Matter?

When a bug is reported vaguely, the backend engineer becomes a detective before they can become a problem-solver.

For every vague reporting, we have the same extensive loop:

• "What were you doing when it happened?"
• "Can you send a screenshot?"
• "Which page/button/action?"
• "Is this still happening?"

Before the real debugging starts, there's already an entire slack thread, or a 10-min (could be longer) call trying to reproduce the issue reported. Multiply that across a sprint, across a team, across a project timeline. It adds up to real, avoidable delay.

Good error reporting is a force multiplier. It's often the difference between a bug fixed in 15 minutes and one that takes up half a sprint.

What Makes a Developer's Error Report Different From a User's?

I like to tell engineers on my team that while end users describe symptoms, developers should report evidence.

An end user is allowed to say "it's not working." They don't have access to dev tools, they don't know what an endpoint is, and they shouldn't have to.

A developer reporting a bug, especially to another developer, has no such excuse. Precision and clarity is the key differentiator.

What makes an Error Report Developer-Level Precise and Clear?

1. Copy the Exact Error Message:

This isn't the UI-wrapped error. This is the literal text from the literal error from the browser console, copied — not paraphrased. Paraphrasing an error message makes it lose its 'stew'. It loses the specific detail (error codes, stack traces, variable names) that often points straight to the cause.

2. Get the Failing Endpoint:

Which API call actually failed? This is visible in the Network tab. Rather than guessing across an entire codebase, it immediately tells the backend engineer which controller, service, or route to look at.

3. Note The Exact Time or Time Range:

This is a crucial part of reporting to help the backend engineer easily trace the logs on server-side produced by the failing endpoint. It is important to note that, "It happened this morning" is not a timestamp.

4. Copy the Request and Response Details:

The status code (400? 401? 500?), the request payload, and the response body are all visible in the Network tab. A good 70% of the time, they reveal why something failed, not just that it failed.

5. Provide Steps to Reproduce:

What sequence of actions led to the error? Can it be triggered consistently, or was it a one-off?

6. Share What's Already Been Tried:

This one matters more between developers than anywhere else. If you're a backend developer reporting an issue to another backend developer, saying "I tried restarting the queue worker and clearing the Redis cache, still fails" saves your teammate from repeating dead ends.

7. Provide Environment Context:

Local, staging, or production? Which branch or deployment? A bug that only happens in staging because of a stale environment variable looks very different from one that's broken everywhere.

A Brief Walkthrough: Using the Network Tab to Report Errors Properly

If there's one browser tool every frontend developer should be fluent in before reporting a bug to a backend engineer, it's the Network tab.

Here's a simple walkthrough:

1. Open dev tools (F12 or right-click → Inspect) and go to the Network tab.
2. Reproduce the issue — perform the action that triggers the bug while the Network tab is recording.
3. Find the failing request. Failed requests are usually easy to spot — they'll show a red status or a 4xx/5xx status code in the Status column.
4. Click on that request. This opens a detail panel with several useful tabs:
   • Headers — shows the endpoint URL, request method (GET, POST, etc.), and status code.
   • Payload/Request — shows exactly what data was sent to the server.
   • Response — shows exactly what the server sent back, often including a specific error message from the backend itself.
   • Timing — shows how long the request took, useful for diagnosing timeouts.
5. Copy, don't summarize. Copy the request URL, the response body, and the status code directly into your bug report. A screenshot of this panel works too — as long as all four pieces (URL, method, status, response) are visible.
6. Cross-check the Console tab for any related JavaScript errors that occurred alongside the failed request.

If you've never used the Network tab while reporting a bug, this habit alone will improve the quality of your reports overnight.

Good bug report

POST /api/user/avatar-upload returned 413 Payload Too Large at 2:14 PM.
The request payload exceeded the upload size limit.

This single sentence tells the backend engineer exactly where to look, cutting the back-and-forth down to zero.

---

Conclusion

None of this is complicated. It's not asking frontend developers to understand backend architecture, or expecting anyone to debug someone else's code. It's just asking that reports come from a developer's vantage point.

Small habits like this compound. They reduce the back-and-forth between developers and development units, cut down the time spent debugging and deciphering vague reports, and, maybe most importantly, they build a culture of precision within a team. On teams like IDC-FUTO Build Team, where everyone's time is already stretched thin, that precision isn't a nice-to-have. It's what keeps a project moving.

I'd honestly love to see developers do better when communicating issues.