ErrorBase
Referencia técnica independienteSitio oficial
  • Software y sistemas
  • Servicio HTTP

500

HTTP 500 en servicio web: condición inesperada en el servidor

Verificada con fuentes2 fuentesRevisada 3 oct 2026
¿Viene un técnico? Mira los 3 pasos que debe enseñarte

Nivel de riesgo

Precaución

Actúa con cuidado; puede requerir técnico si persiste.

Urgencia

Media — atiéndelo hoy

Respuesta rápida

El servidor encontró una condición inesperada y no pudo completar tu petición; el fallo está en el servidor, no en tu equipo. Reintenta más tarde y, si sigue, comunica al sitio la hora, la URL y el código de referencia si aparece.

Seguridad primero

Antes de continuar

  • Tras un 500 al pagar o enviar un pedido, comprueba si se registró antes de repetirlo: la petición pudo aplicarse aunque la respuesta fuera un error.
  • Si eres el operador, no muestres trazas de la excepción en la página de error pública; guárdalas en los registros y enseña solo un identificador.

Puedes hacerlo con seguridad

  • Qué dice la página de error
  • Reintento sin duplicar pagos ni pedidos
  • Aviso al responsable del sitio
  • La petición fallida en los registros del servidor
  • Coincidencia con un despliegue o cambio reciente

Deja estas tareas a un profesional cualificado

  • No intentes esta tarea profesional: Correlacionar el reporte con su traza
  • No intentes esta tarea profesional: Comprobar la corrección con la misma petición
  • No intentes esta tarea profesional: Página de error útil para el visitante

Lo que un técnico debe poder justificar

Viene un técnico a casa

Estos son los pasos que tiene que hacer y enseñarte. Márcalos mientras trabaja: si se salta pasos, no aceptes el cambio de pieza.

No son instrucciones para que abras o manipules el equipo. Son las comprobaciones que deben sostener una conclusión técnica.

  1. Correlacionar el reporte con su traza

    Qué haceEl desarrollador localiza la petición del reporte por hora e identificador y lee la excepción o error que la produjo.

    Te tiene que enseñarla entrada de registro con la misma hora e identificador que el reporte.

    Por escritola causa encontrada y el cambio aplicado.

  2. Comprobar la corrección con la misma petición

    Qué haceTras corregir o revertir, el equipo repite la misma URL o acción que fallaba y revisa que los registros ya no muestran el error.

    Te tiene que enseñarla respuesta correcta de la misma petición.

    Por escritoversión desplegada, hora de la corrección y resultado de la prueba.

  3. Página de error útil para el visitante

    Qué haceEl equipo revisa que la respuesta 500 incluya una explicación y si el problema es temporal o permanente, como recomienda RFC 9110, más un identificador de referencia.

    Te tiene que enseñarun ejemplo de la página de error.

    Por escritoque no muestra trazas internas ni datos sensibles.

Antes de aceptar una pieza o reparación

Aún no ha demostrado nada. No aceptes un cambio de pieza solo por el código.

Comprobaciones y evidencia, paso a paso

Sigue el orden documentado. Un código identifica el sistema afectado, pero por sí solo no demuestra qué pieza está averiada.

  1. 1

    Qué dice la página de error

    Sin herramientas especiales

    Procedimiento

    Quién:
    el visitante.
    Cómo:
    lee el texto de la página de error antes de cerrarla.
    Resultado que importa:
    si indica que el problema es temporal o permanente y si muestra un código de referencia o identificador.
    Si indica que es temporal:
    espera y vuelve a intentarlo más tarde.
    Si muestra un identificador:
    anótalo tal cual; permite al operador encontrar tu petición en sus registros.
    Evidencia a conservar:
    captura de la página con la hora visible.

    Evidencia: RFC 9110 - HTTP Semantics

  2. 2

    Reintento sin duplicar pagos ni pedidos

    Sin herramientas especiales

    Procedimiento

    Quién:
    el visitante.
    Cómo:
    si solo estabas viendo una página, recárgala pasados unos minutos. Si enviaste un formulario, pago o pedido, no lo reenvíes hasta comprobar si se registró (correo de confirmación, historial de la cuenta).
    Resultado que importa:
    si la misma página o acción vuelve a fallar.
    Si ya funciona:
    no hace falta nada más; conserva la hora por si el operador la pide.
    Si sigue fallando:
    pasa a informar al sitio.
    Evidencia a conservar:
    hora de cada intento y si llegó o no una confirmación.

    Un envío que devolvió 500 puede haberse aplicado igualmente. Reenviarlo sin comprobar puede duplicar un cargo o un pedido.

    Evidencia: RFC 9110 - HTTP Semantics

  3. 3

    Aviso al responsable del sitio

    Sin herramientas especiales

    Procedimiento

    Quién:
    el visitante.
    Cómo:
    consulta la página de estado del servicio si la publica y, si no hay incidencia anunciada, escribe por su canal de soporte.
    Resultado que importa:
    que el operador reciba datos para localizar tu petición.
    Si hay una incidencia publicada:
    espera a que la cierren; no hace falta reportar.
    Si no la hay:
    envía la hora exacta con zona horaria, la URL, lo que estabas haciendo y el identificador si apareció.
    Evidencia a conservar:
    copia del mensaje enviado y la captura.

    No incluyas contraseñas, tokens ni datos de tarjeta en el reporte.

    Evidencia: RFC 9110 - HTTP Semantics

  4. 4

    La petición fallida en los registros del servidor

    Requiere herramientas

    Procedimiento

    Quién:
    el operador o desarrollador del sitio.
    Cómo:
    busca en los registros de la aplicación y del servidor por la hora del fallo y por el identificador de petición o de correlación.
    Resultado que importa:
    una entrada de error o excepción asociada a esa petición.
    Si aparece:
    esa entrada, no el código 500, es la que señala el componente que falló.
    Si no aparece en la aplicación:
    comprueba si el 500 lo generó otra capa (proxy, balanceador, CDN) revisando sus registros con la misma hora.
    Evidencia a conservar:
    extracto del registro con hora e identificador, sin secretos ni datos personales.

    Solo el operador con acceso a los sistemas. Al compartir registros, elimina credenciales y datos personales.

    Evidencia: RFC 9110 - HTTP Semantics

  5. 5

    Coincidencia con un despliegue o cambio reciente

    Requiere herramientas

    Procedimiento

    Quién:
    el operador o desarrollador del sitio.
    Cómo:
    compara la hora del primer 500 con el historial de despliegues y cambios de configuración.
    Resultado que importa:
    si los errores empiezan justo después de un cambio.
    Si coinciden:
    ese cambio es el primer candidato; revierte o corrige siguiendo el procedimiento del equipo.
    Si no coinciden:
    sigue con lo que muestren los registros.
    Evidencia a conservar:
    versión desplegada, hora del despliegue y hora del primer error.

    Solo el operador. Reiniciar o revertir producción debe seguir el procedimiento aprobado; reinicios repetidos pueden borrar el estado que explica el fallo.

    Evidencia: RFC 9110 - HTTP Semantics

Dónde se aplica este código

Un código solo tiene significado dentro del producto y la versión correctos.

Ámbito principal

Sistema
Software y sistemas
Marca
HTTP
Tipo de producto
Servicio HTTP

Variantes conocidas del código

  • 500 Error interno del servidor
  • 500 Errore interno del server
  • 500 Internal Server Error
  • 500 Interner Serverfehler
  • Bosch 500 bici elettrica
  • Bosch 500 bicicleta eléctrica
  • Bosch 500 E-Bike
  • Bosch 500 eBike
  • Bosch 500 vélo électrique
  • Bosch eBike code 500
  • Bosch eBike error 500
  • Bosch eBike Fehler 500
  • Bosch eBike Fehlercode 500
  • code Bosch eBike 500
  • code erreur 500
  • codice Bosch eBike 500
  • código Bosch eBike 500
  • erreur Bosch eBike 500
  • error Bosch eBike 500
  • errore Bosch eBike 500
  • HTTP 500
  • HTTP status 500
  • status code 500

Qué significa

RFC 9110 (§15.6.1) define 500 como que el servidor encontró una condición inesperada que le impidió completar la solicitud; IANA lo registra como «Internal Server Error». Pertenece a la clase 5xx: el servidor sabe que ha fallado. La norma no indica qué componente falló; eso solo lo muestran los registros del servidor para esa petición. No es lo mismo que 501 (el servidor no soporta la función pedida) ni que 503 (sobrecarga temporal o mantenimiento, que puede llevar Retry-After).

Advertencias y condiciones de parada

  • Precauciónadvertencia editorial

    Tras un 500 al pagar o enviar un pedido, comprueba si se registró antes de repetirlo: la petición pudo aplicarse aunque la respuesta fuera un error.

    Evidencia: RFC 9110 - HTTP Semantics

  • Seguroadvertencia editorial

    Si eres el operador, no muestres trazas de la excepción en la página de error pública; guárdalas en los registros y enseña solo un identificador.

    Evidencia: RFC 9110 - HTTP Semantics

Síntomas y causas

Causas probables · en orden

  • Condición inesperada en el servidorConfirmada

    Es lo único que el código demuestra: el servidor no pudo completar la petición por algo que no esperaba. Se distingue de 501, que indica una función no soportada, y de 503, que indica sobrecarga temporal o mantenimiento.

    Evidencia: IANA HTTP Status Code Registry · RFC 9110 - HTTP Semantics

  • Fallo ligado a una página o acción concretaPosible

    Si solo falla una URL o una acción (por ejemplo, enviar un formulario) y el resto del sitio responde, el operador debe buscar en sus registros el error de esa ruta. Sigue siendo un fallo del servidor, no del visitante.

    Evidencia: RFC 9110 - HTTP Semantics

  • Fallo que afecta a todo el servicioPosible

    Si todas las páginas devuelven 500, el operador debe revisar en sus registros qué componente común falla y si coincide con un cambio reciente. La norma no dice cuál es; hay que comprobarlo.

    Evidencia: RFC 9110 - HTTP Semantics

Técnico virtual

¿Sigue apareciendo 500 tras comprobarlo?

Responde unas preguntas para acotar la causa probable y la siguiente acción segura. Es una orientación - nunca sustituye a un profesional.

Iniciar diagnóstico

Fuentes y referencias técnicas

  1. 1

    IANA HTTP Status Code Registry

    Internet Assigned Numbers Authority · 2025 · standard

  2. 2

    RFC 9110 - HTTP Semantics

    IETF / RFC Editor · 2022 · standard

Fuentes: IANA HTTP Status Code Registry · RFC 9110 - HTTP Semanticsrevisado 2026-10-03 · verificado

¿Te ha resultado útil esta ficha?