¿Prefieres que lo revisemos nosotros?
Cuéntanos en qué punto estás y te decimos, sin rodeos, lo más indicado para tu caso.
Por qué pruebas y producción no son lo mismo en n8n
Cuando pruebas un flujo en n8n, el entorno está bajo tu control. Tú decides qué datos entran, cuándo se ejecuta el flujo y cuántas veces. Puedes repetir la misma prueba con los mismos datos hasta que funcione.
En producción, todo eso cambia. Los datos los genera alguien externo, un cliente que rellena un formulario, una API que responde con un formato ligeramente distinto, un sistema que envía la información a una hora que no esperabas. El volumen puede ser diferente. El orden puede ser diferente. Y los datos casi nunca son tan limpios y predecibles como los que usas en pruebas.
En pruebas tú controlas el experimento. En producción, el experimento te controla a ti.
La mayoría de fallos en producción no son errores del flujo, son situaciones que el flujo no estaba preparado para gestionar porque en pruebas nunca aparecieron.
Las causas más habituales del fallo al pasar a producción
1. Los datos de prueba eran perfectos. Los datos reales, no
En pruebas introduces tú mismo los datos. Pones un email bien formateado, un nombre sin caracteres raros, un número de teléfono con el formato exacto que espera el flujo. Todo encaja porque tú te has asegurado de que encaje.
En producción, los datos los introduce un usuario real. Ese usuario puede dejar un campo vacío que tú nunca dejaste vacío en tus pruebas. Puede escribir su nombre en mayúsculas, con tildes, con un espacio al final. Puede poner un teléfono con prefijo internacional cuando tu flujo espera solo nueve dígitos.
El flujo no estaba preparado para eso porque nunca lo vio en pruebas.
¿Cómo detectarlo? Abre la ejecución fallida en producción y compara el INPUT del primer nodo con los datos que usabas en pruebas. Busca diferencias: campos vacíos, formatos distintos, caracteres inesperados. La diferencia entre tus datos de test y los datos reales casi siempre está ahí.
2. El webhook de pruebas y el de producción son URLs distintas
n8n genera dos URLs diferentes para cada webhook: una para pruebas (con /test/ en la ruta) y otra para producción. Cuando estás en el editor y haces clic en «Execute Node», el flujo escucha en la URL de pruebas.
Si tu formulario, tu app o tu sistema externo está enviando los datos a la URL de pruebas en lugar de a la de producción, el flujo solo funcionará cuando estés en el editor con el nodo activo en modo test. En cuanto salgas del editor o intentes ejecutarlo en producción, dejará de recibir nada.
¿Cómo detectarlo? Copia la URL de producción del nodo Webhook (es la que aparece como «Production URL» y no contiene /test/) y verifica que es exactamente esa la que está configurada en el origen. Un solo carácter de diferencia es suficiente para que nada llegue.
3. Las credenciales de prueba tienen permisos distintos a las de producción
Esto ocurre más de lo que parece. En desarrollo usas una cuenta de prueba del CRM, una API key de sandbox, un entorno de staging. Todo funciona. Cuando cambias a producción, las credenciales son otras, y esas otras credenciales tienen permisos distintos, límites de uso diferentes o acceso solo a determinados módulos.
El flujo hace exactamente lo mismo que hacía antes, pero la API de producción le responde de forma distinta porque la credencial tiene restricciones que la de pruebas no tenía.
¿Cómo detectarlo? Verifica que las credenciales configuradas en el flujo en producción son las correctas y que tienen los permisos necesarios. Haz un test manual desde el nodo de la integración con las credenciales de producción activas. Si el test falla donde antes no fallaba, el problema está en los permisos o en la configuración de la cuenta.
4. El volumen en producción activa comportamientos que en pruebas nunca aparecieron
En pruebas ejecutas el flujo una vez, quizás dos. En producción puede ejecutarse diez veces en un minuto si llegan diez solicitudes a la vez. Hay APIs que tienen límites de llamadas por segundo. Hay nodos que no están preparados para procesar en paralelo. Hay flujos que escriben en una hoja de cálculo y se bloquean cuando dos ejecuciones intentan escribir al mismo tiempo.
En pruebas esto nunca pasa porque nunca mandas diez peticiones seguidas. En producción puede pasar desde el primer día.
¿Cómo detectarlo? Revisa si los fallos en producción se concentran en momentos de mayor actividad, horas punta, días de campaña, tras el envío de un email masivo. Si los errores aparecen en ráfaga y no de forma aislada, es probable que el problema sea de concurrencia o de límites de la API.
5. Hay nodos que dependen del contexto del editor para funcionar
Algunos nodos en n8n se comportan de forma ligeramente distinta cuando están dentro del editor activo que cuando el flujo corre en segundo plano. El caso más frecuente: nodos que usan expresiones con datos de ejecuciones anteriores ($prevNode, $execution) que solo tienen valor en un contexto determinado.
También ocurre con algunos nodos de tipo Code que hacen referencias a variables globales que solo existen en el entorno de desarrollo, o con configuraciones de timezone que afectan a los nodos de tipo Schedule de forma distinta según el servidor donde corre n8n.
¿Cómo detectarlo? Si el fallo es en un nodo de tipo Code o en expresiones con referencias a contexto de ejecución, revisa que todas las variables que usa el nodo están disponibles en el contexto de producción. Una buena práctica es añadir un nodo Set al principio del flujo que capture y normalice todos los datos de entrada antes de que cualquier otro nodo los use.
6. El trigger de producción no se comporta igual que el trigger de prueba
Cuando pruebas un flujo con trigger de tipo webhook, tú mandas la petición manualmente. Cuando pruebas un flujo con trigger de tipo Schedule, haces clic en «Execute» para forzar la ejecución. En producción, esos triggers funcionan solos, y a veces no arrancan como esperabas.
Un trigger de tipo Schedule puede no ejecutarse si el flujo no está activo en el momento exacto en que debería dispararse. Un trigger de tipo webhook puede no responder si el flujo se reactivó después de una actualización del servidor y la URL cambió. Un trigger de tipo polling puede no detectar los cambios si el intervalo de comprobación es demasiado largo.
¿Cómo detectarlo? Ve a Executions y filtra por el flujo en cuestión. ¿Hay ejecuciones recientes en producción? Si el trigger debería haberse disparado y no hay ninguna ejecución registrada, el problema está en el trigger, no en el flujo. Comprueba que el flujo está activo, que la URL del webhook es la correcta y que las credenciales del trigger tienen los permisos necesarios.
Cómo hacer la transición de pruebas a producción sin sustos
La mayoría de estos problemas se pueden prevenir si sigues un proceso mínimo antes de activar un flujo en producción:
- Prueba con datos reales antes de activar. Antes de poner el flujo en producción, ejecuta una prueba con datos lo más parecidos posible a los que llegará de verdad: un formulario real rellenado por alguien de tu equipo, una petición desde el sistema externo real, no desde Postman o desde tu ordenador.
- Verifica las URLs de webhook en el origen. Antes de activar, abre el formulario, la app o el sistema que va a disparar el trigger y confirma que la URL configurada es la de producción. Cópiala directamente desde el nodo, no la escribas a mano.
- Comprueba las credenciales de producción una a una. Haz un test manual desde cada nodo de integración con las credenciales de producción activas. Si alguno falla en el test manual, no actives el flujo hasta resolverlo.
- Activa el flujo y monitoriza las primeras ejecuciones en tiempo real. Las primeras horas de un flujo en producción son las más críticas. Quédate cerca y revisa manualmente las primeras ejecuciones en Executions para confirmar que los datos llegan y se procesan como esperabas.
- Añade un aviso de confirmación al final del flujo. Un email al equipo, un mensaje en Slack, una fila en una hoja de cálculo. Algo que te confirme que el flujo completó su ciclo. Si deja de llegar ese aviso, sabes que algo ha cambiado.
Un flujo que funciona en pruebas es un punto de partida. Un flujo que funciona en producción es el objetivo real.
¿Prefieres que lo revisemos nosotros?
Cuéntanos en qué punto estás y te decimos, sin rodeos, lo más indicado para tu caso.
Cuándo tiene sentido que lo gestione alguien con experiencia
Si llevas tiempo dando vueltas al mismo flujo y el problema sigue sin aparecer, hay dos posibilidades:
La primera: el fallo está en una capa que no es visible desde el editor de n8n, configuración del servidor, comportamiento específico de la API del servicio externo, logs del sistema que n8n no expone en la interfaz.
La segunda: el diseño del flujo tiene un problema estructural que hace que sea frágil por construcción. No es que algo esté mal configurado, es que el flujo no está preparado para el entorno real, y arreglarlo implica replantearlo.
En Synergy llevamos años poniendo flujos en producción para empresas de distintos sectores. Cuando nos llega un caso así, sabemos exactamente qué diferencias buscar entre el entorno de pruebas y el real, y dónde suelen esconderse los problemas que no se ven a simple vista.
No es que tengamos una fórmula mágica. Es que hemos visto este mismo patrón suficientes veces como para ir directamente a donde está el problema.
La opinión de Synergy
Que un flujo funcione en pruebas y falle en producción no significa que hayas hecho algo mal. Significa que el entorno real es más complejo que el entorno controlado donde lo construiste. Es algo que le pasa a cualquiera que trabaja con automatizaciones.
Lo que marca la diferencia es saber dónde buscar. Los datos de entrada, las URLs del webhook, las credenciales, el volumen, las referencias de contexto, el comportamiento del trigger, cada uno de estos puntos puede ser la causa, y cada uno tiene su forma específica de detectarse.
Si con lo que has leído aquí no has encontrado el problema, es probable que estés ante uno de los casos que requieren mirar más a fondo. Y si lo que quieres es que alguien que lo hace a diario lo resuelva contigo (o que diseñe desde el principio un flujo preparado para producción) eso también es lo que hacemos.
La IA trabaja. Las personas deciden. Y para que funcione de verdad, alguien tiene que asegurarse de que el puente entre las pruebas y la realidad está bien construido.
¿Quieres que revisemos tu flujo?
Hablemos 30 minutos y te decimos qué está pasando.