[▲ Vercel Community](/) · [Categories](/categories) · [Latest](/latest) · [Top](/top) · [Live](/live) [Discussions](/c/community/4) # Silent 500 Error on POST /api/auth/login - No Function Logs 185 views · 1 like · 3 posts M2thedsquared (@m2thedsquared) · 2025-04-10 We use the Hobby version as we are trying out different providers for current deployments. **Deployment URL:** `https://wblareporting-backend-dev.vercel.app` **(Associated Frontend/Origin):** `https://wblareporting-dev.vercel.app` **Problem:** We are consistently receiving an HTTP 500 Internal Server Error response when sending a `POST` request to `/api/auth/login` on our development deployment (`wblareporting-backend-dev.vercel.app`). **Key Issue & Evidence:** The primary issue is that despite the client receiving a 500 error, there are **absolutely no logs generated** in the Vercel Function Runtime Logs corresponding to the execution of the function handling this specific `POST /api/auth/login` request. * **Extensive Logging Added:** We have added detailed `console.log` statements throughout our Node.js/Express application: * At the very beginning of `app.js` using global middleware (position 0, before CORS and body-parser). * Inside specific middleware (`express-validator`) for the `/api/auth/login` route. * Inside the route handler in `routes/authRoutes.js`. * Inside the controller function (`controllers/authController.js`). * **Logs Missing ONLY for Failing Request:** While attempting login around **Thursday, April 10, 2025, 12:30 PM EDT** and **12:38 PM EDT** (corresponding roughly to 16:30 UTC and 16:38 UTC), no logs related to `POST /api/auth/login` (e.g., `@@@@ GLOBAL LOGGER START (POS 0): POST /api/auth/login @@@@`) appeared in the Vercel Runtime Logs. * **Logs Present for OTHER Requests:** During the exact same timeframes, other requests to the *same deployment* were successfully processed and logged by the *same global middleware*. For example: * `GET /api/health-check` logged successfully around **Apr 10 12:30:00 PM EDT** (`@@@@ GLOBAL LOGGER END (POS 0): GET /api/health-check - Status: 200...`). * `GET /` logged successfully around **Apr 10 12:38:40 PM EDT** (`@@@@ GLOBAL LOGGER END (POS 0): GET / - Status: 200...`). * **Valid Request Body:** We have confirmed via browser developer tools that the request payload being sent is valid JSON (e.g., `{"login": "user@example.com", "password": "PASSWORD_MASKED"}`). * **Minimal Handler Test:** A previous test using a minimal handler directly in `authRoutes.js` for `POST /api/auth/login` (which just sent `res.status(418).json(...)`) *did* successfully execute and return the 418 response to the browser, proving the route *can* be reached by the function under simple conditions. However, restoring the full application logic reintroduced the silent 500 failure. **Conclusion:** The evidence strongly suggests that the `POST /api/auth/login` request is encountering an error within the Vercel platform/infrastructure *before* our Node.js application code (`app.js`) is successfully invoked or allowed to log, despite the client receiving a 500 status code. Amy Egan (@amyegan) · 2025-04-10 It looks like the path [/api/auth/login](https://wblareporting-backend-dev.vercel.app/api/auth/login) doesn't exist in your project. The project returns `{"status":"error","message":"Route not found","path":"/api/auth/login"}` I can confirm these 404 errors are in the [runtime logs](https://vercel.com/docs/runtime-logs) for your backend project with the `@@@@ GLOBAL LOGGER START...` details included. The frontend project does throw a 500 error, but that *might* not appear in the runtimes logs depending on how your project is handling the error. Keep in mind that only 1 hour of logs are retained on the Hobby plan, so you need to check the logs fairly quickly after triggering the error. M2thedsquared (@m2thedsquared) · 2025-04-10 · ♥ 1 Thanks Amy! I was looking at the logs immediately afterwards and the particular larger 500 error wasn't showing. I could see it in the DOM, which is why I said it was silent. But, after seeing you run or someone run I saw the error. I tried again, it didn't show up immediately like the other runtimes did. I waited a few minutes and sure enough it popped up. That allowed us to track down the culprit, which was a database schema, which is what I thought, but couldn't find where. Just as an FYI, the path existed, it was in the auth section `app.use('/api/auth', authRoutes);` in `app.js` You at least had us look again and realize that the runtime wasn't instant, per sè.