¿Qué es un Heisenbug?
Cultura de ingeniería y práctica de software
Un Heisenbug es un error que cambia, se oculta o desaparece cuando se intenta observarlo. Añadir registros, conectar un depurador, pausar la ejecución o recompilar con configuraciones distintas hace que el fallo se desplace o se esfume. El término es parte del folclore de la programación y designa errores cuyo comportamiento se altera por la propia inspección, generalmente porque el tiempo de ejecución, la disposición de la memoria, las optimizaciones o la concurrencia cambian en el momento en que se va a buscar el problema.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
Un Heisenbug es el equivalente en software de ese ruido extraño que desaparece en cuanto el mecánico abre el capó. El problema es real, pero el acto de comprobarlo ha alterado las condiciones que lo provocaban. Por eso estos errores tienen tan mala fama: pueden hacer que un equipo se sienta supersticioso cuando la causa real es simplemente escurridiza e incómoda.
En el fondo, las razones suelen ser bastante ordinarias. Un punto de interrupción da más tiempo a los hilos de ejecución. Una instrucción de impresión cambia el tiempo de ejecución y, a veces, las direcciones de memoria. Una compilación de depuración reorganiza la memoria. Una herramienta de rastreo añade sobrecarga. Una compilación de producción activa las optimizaciones del compilador. Lo que parece un fantasma es, con frecuencia, una condición de carrera, un comportamiento indefinido o una configuración de entorno muy concreta.
El nombre folclórico importa porque ofrece a los ingenieros una forma compartida de decir: "Cuidado, el microscopio está moviendo la muestra".
Por qué importa
Los Heisenbugs importan porque penalizan el movimiento de depuración más obvio: tocar el programa para ver qué hace. Si el primer instinto es la inspección intrusiva, es posible borrar accidentalmente el comportamiento mismo que se necesita estudiar. Eso cambia no solo el enfoque técnico, sino también el social. Una persona que dice "lo vi fallar, pero ahora no falla con el depurador" no está siendo necesariamente imprecisa. Puede estar describiendo una pista importante.
Esto es especialmente relevante en sistemas con concurrencia, comportamiento en tiempo real, servicios distribuidos o gestión frágil de la memoria. En esos entornos, pequeños retrasos o cambios de disposición pueden activar y desactivar un fallo. Los lectores de negocio también deberían prestarle atención, porque esta es una de las razones por las que los incidentes en producción pueden ser lentos y costosos de identificar. El software no solo está mal: está mal de una manera que resiste la observación.
Entender el término también ayuda a los equipos a evitar malos hábitos. Un Heisenbug no es una licencia para el misticismo. Es un recordatorio de recopilar evidencias de formas menos disruptivas, preservar el estado de fallo y diseñar sistemas para que los fallos esquivos dejen mejores rastros.
Cómo funciona
El origen del nombre
Heisenbug proviene del argot antiguo de los hackers y quedó registrado en el Jargon File. Bruce Lindsay describió más tarde el sentido original de forma muy directa: cuando miras el error, desaparece. El chiste alude a Werner Heisenberg y a la idea de que la observación cercana afecta a lo que se puede ver.
Dicho esto, el término es más un juego de palabras de programadores que una clase de física. La gente suele relacionarlo con el efecto observador. Lo importante en ingeniería no es la analogía científica perfecta, sino la advertencia práctica de que el acto de inspección puede perturbar el sistema.
Por qué la observación cambia el comportamiento
El software se ejecuta dentro de una red de tiempos, memoria, planificación, E/S, cachés y sistemas externos. Muchas herramientas de inspección alteran esa red. Los puntos de interrupción detienen el mundo. El registro adicional cambia la velocidad de ejecución y, a veces, las direcciones de memoria. Ejecutar con un depurador puede desactivar ciertas optimizaciones. Las compilaciones de producción y de depuración no siempre organizan los datos de la misma manera. En código concurrente, pequeños cambios en el orden pueden ser determinantes.
Por eso un Heisenbug aparece con frecuencia en condiciones de carrera, errores de uso tras liberación de memoria, lecturas sin inicializar o código que depende de tiempos accidentales. El error puede no ser raro porque sea profundo, sino porque las circunstancias exactas son muy concretas y fáciles de perturbar.
Cómo lo abordan los ingenieros en la práctica
Cuando un error se comporta así, los equipos intentan que la observación sea menos intrusiva. Se apoyan en volcados de memoria, búferes de rastreo, registros centralizados, telemetría muestreada, indicadores de funcionalidad, repeticiones controladas e instantáneas del entorno. Comparan las compilaciones de producción y de depuración. Preservan las semillas aleatorias, los rastros de hilos, los identificadores de solicitud y la configuración exacta de la ejecución fallida.
Otra táctica útil es convertir el error escurridizo en uno reproducible. En el argot hacker, la idea contraria es el Bohr bug, un error que se comporta de forma consistente. Gran parte del trabajo aquí consiste en encontrar la configuración que estabilice el fallo lo suficiente para estudiarlo. Una vez que el fallo deja de moverse, la investigación se vuelve mucho menos teatral y mucho más productiva.
Ejemplos
Un servicio de backend corrompe ocasionalmente una cola de trabajos bajo tráfico intenso. El error desaparece cada vez que un ingeniero avanza paso a paso por la sección crítica. La razón es el tiempo de ejecución. Pausar un trabajador el tiempo suficiente permite que el trabajador en competencia termine limpiamente, de modo que la condición de carrera nunca se produce. El depurador no arregló nada: simplemente reorganizó la planificación.
Un programa en C o C++ falla en las compilaciones de producción pero funciona perfectamente en modo de depuración. Tras varias rondas de confusión, el equipo descubre un puntero obsoleto. La disposición de memoria diferente y las comprobaciones adicionales de la compilación de depuración enmascaran el acceso inválido. La compilación de producción elimina ese colchón accidental y el fallo reaparece.
Un fallo gráfico aparece en una pantalla física pero desaparece en capturas de pantalla y sesiones remotas. La ruta de renderizado cambia lo suficiente bajo las herramientas de captura y acceso remoto como para que el modo de fallo original ya no esté presente. Eso hace que el error parezca absurdo hasta que alguien recuerda que la observación también puede cambiar la pila de renderizado.
Malentendidos frecuentes
Un Heisenbug no es lo mismo que cualquier error intermitente. Algunos errores simplemente se desencadenan por datos poco frecuentes o por un trabajo programado semanal. Un Heisenbug verdadero cambia de carácter según la forma en que se lo observa.
Tampoco significa que el error sea imaginario. "No se puede reproducir con el depurador" no es lo mismo que "no ocurrió". De hecho, esa discrepancia suele ser la pista más importante disponible.
Otro malentendido es que los Heisenbugs solo aparecen en sistemas muy exóticos. Son comunes en software ordinario que combina concurrencia, código nativo, tiempos de red, cachés, indicadores de funcionalidad o puntos de integración frágiles.
También se usa el término con demasiada ligereza para cualquier fallo molesto. Si el error se reproduce de forma fiable una vez que se conoce la configuración correcta, puede ser raro, pero ya no tiene la forma característica de un Heisenbug.
Por último, más registros no es automáticamente mejor. A veces el registro adicional es exactamente lo que hace que el fallo retroceda. La buena observabilidad sigue siendo vital, pero debe diseñarse teniendo en cuenta el nivel de intrusión.
Riesgos y límites
El principal riesgo del término es que puede convertirse en un encogimiento de hombros. Los equipos a veces dicen "Heisenbug" con el mismo tono con que la gente dice "son cosas que pasan". Eso le resta utilidad a la palabra. La etiqueta debería agudizar la investigación, no ponerle fin.
También existe el peligro del teatro accidental. Los nombres exóticos pueden hacer que el trabajo de ingeniería ordinario suene mágico. La mayoría de los Heisenbugs siguen reduciéndose a causas conocidas: estado compartido, ordenación, uso inseguro de la memoria o diferencias de entorno muy concretas. El folclore es pintoresco, pero el remedio suele ser la recopilación paciente de evidencias.
En el otro extremo, no todo fallo difícil merece la etiqueta. A veces el problema es simplemente una configuración de prueba deficiente, datos locales obsoletos o un informe de error incompleto. Si "Heisenbug" se convierte en la primera explicación en lugar de una hipótesis de trabajo posterior, puede distraer de comprobaciones más sencillas.
El límite saludable es este: usar el término cuando la observación en sí parece parte del problema, y pasar rápidamente a la captura y reducción disciplinadas.
Qué hacer a continuación
Si este patrón aparece en el equipo, conviene invertir en captura de evidencias que no dependa de detener el mundo. Hay que mantener símbolos de producción, registros centrales, identificadores de rastreo, volcados de memoria, repeticiones de solicitudes e instantáneas del entorno. Facilitar que los ingenieros puedan comparar la ejecución fallida con una conocida como correcta.
Conviene preservar las condiciones del fallo antes de que nadie empiece a indagar. Hay que animar a los equipos a duplicar el estado, guardar los artefactos y solo entonces comenzar una inspección más intrusiva. Unos minutos de disciplina aquí pueden ahorrar días de conjeturas más adelante.
También merece la pena dedicar tiempo a reducir el no determinismo. Las pruebas inestables, el estado compartido oculto, la reproducibilidad débil y la paridad de compilación deficiente hacen que los Heisenbugs sean más probables y más difíciles de detectar. Esto no es mantenimiento rutinario: es trabajo de fiabilidad.
Por último, conviene resistir la cultura del héroe. El objetivo no es admirar a quien finalmente doma al fantasma, sino construir sistemas en los que sobrevivan menos fantasmas desde el principio.
¿Tiene alguna pregunta o sugerencia, o quiere saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Una prueba inestable es lo mismo que un Heisenbug?
No siempre. Una prueba inestable puede fallar por tiempos de ejecución, fixtures compartidos, dependencia del orden o aserciones débiles. Se convierte en algo parecido a un Heisenbug cuando la instrumentación o la inspección cambian el propio fallo.
¿Por qué los puntos de interrupción hacen desaparecer estos errores?
Porque los puntos de interrupción alteran el tiempo de ejecución de forma drástica. En código concurrente o sensible al tiempo, eso puede eliminar el orden exacto que causó el fallo en primer lugar.
¿Cuál es lo opuesto de un Heisenbug?
En el argot de los programadores, el Bohr bug es el contraste clásico: un error sólido y reproducible que se comporta con suficiente consistencia como para estudiarlo directamente.
¿Los Heisenbugs solo se encuentran en código de sistemas de bajo nivel?
No. Son comunes allí, pero los sistemas web, las aplicaciones móviles, los servicios distribuidos y las plataformas de datos también pueden generarlos cuando el tiempo de ejecución, el estado o el entorno son frágiles.
¿Debo añadir más registros cuando sospecho un Heisenbug?
A veces, pero con cuidado. El registro adicional puede ayudar, aunque también puede perturbar el sistema. Conviene preferir la observabilidad estructurada y preexistente siempre que sea posible, y comparar métodos intrusivos y menos intrusivos.
¿Cómo explico un Heisenbug a personas que no son ingenieras?
Una forma sencilla es: el error es real, pero las herramientas utilizadas para inspeccionarlo cambiaron las condiciones que lo causaban, por lo que el fallo dejó de comportarse con normalidad mientras se estaba observando.
Fuentes
A Conversation with Bruce Lindsay (ACM Queue). First hand explanation of the original sense of Heisenbug and why the term referred to bugs that vanish when examined.
A Conversation with Bruce Lindsay: Designing for failure may be the key to success (ACM Queue). Corroborating source for Bruce Lindsay's direct remarks on what the term originally meant.