Códigos que pone el propio registro de errores (registro.md) cuando la excepción no trae code: unhandled (500 no atrapado), cors_origin_rejected (el CORS rechazó el origen) y error_events_overflow (lo que no cupo en memoria en un minuto). Una excepción sin code se registra como http_<status>: no es un código del catálogo, ver «Excepciones sin código».
Para toda la familia
Lo que un código no dice lo hereda de aquí.
Cómo se detecta
yarn -s boost errores resumen y yarn -s boost errores ver <código>; en Render, [errors] 5xx code=… status=… count=… method=… route=… y [errors] SPIKE code=… count=….
Qué hacer
Cada ficha dice qué mirar. Para http_<status>, la ruta que guarda el registro dice qué excepción fue.
El CORS de main.ts rechazó la petición porque el Origin no está permitido (CORS_ALLOWED_ORIGINS y los fijos de main.ts). Hoy responde 500 con el texto genérico («Ocurrió un error inesperado…») sin ruta, porque el rechazo es un Error común; el registro lo cuenta aparte para no mezclarlo con unhandled.
Causa típica
Un navegador en un dominio que no es el del front (una vista previa de Vercel nueva, un dominio de un cliente, un bot), o un front local que apunta a prod.
Cómo detectarlo
yarn -s boost errores ver cors_origin_rejected (método y entidad 0) y [errors] 5xx code=cors_origin_rejected … route=(sin ruta) en Render.
Qué hacer
Si el origen es legítimo, agregarlo a CORS_ALLOWED_ORIGINS en Render. Si no, es ruido: no hay nada que arreglar. (Corrección propuesta, no hecha: que el rechazo responda 403 en vez de 500.)
Fila del registro de errores (status 0, ruta y entidad */0) que suma los errores que no cupieron en memoria en un minuto: el registrador guarda a lo sumo ERROR_EVENTS_MAX_KEYS combinaciones distintas por minuto (2000 por defecto) y el resto solo se cuenta aquí.
Cómo detectarlo
yarn -s boost errores resumen (status 0) o [errors] SPIKE code=error_events_overflow en Render.
Qué hacer
Hubo una ráfaga de errores muy variados (muchas rutas o entidades a la vez): yarn -s boost errores resumen --dias 1 dice qué la causó. Subir ERROR_EVENTS_MAX_KEYS solo si esa ráfaga es normal.
Error no atrapado en una petición HTTP: no era una excepción de Nest, así que Nest respondió 500 con el texto genérico (en español desde el 2026-10-21: «Ocurrió un error inesperado…»; antes Internal server error) y escribió el stack (ExceptionsHandler). Es el código que el registro de errores le pone a esos 500.
Causa típica
Un bug: un TypeError, una consulta que falló sin atraparse, una librería que lanzó un Error común. Responde 500 aunque la culpa sea del dato que llegó.
Cómo detectarlo
yarn -s boost errores ver unhandled (ruta y entidad, con el último requestID) y [errors] 5xx code=unhandled … en Render. El stack está en Render en la misma petición: yarn -s boost ops logs "<requestID>".
Qué hacer
Leer el stack de esa petición y corregir el código: atrapar el caso y responder una excepción HTTP con code (que entre al catálogo) en vez de un 500.
Texto generado desde el catálogo de errores de BoostAPI. Para corregirlo, se cambia allá y se sincroniza: verMantener esta documentación. También enMarkdown.
