La agencia de depuración n8n.Reparado, y que aguanta.
Un webhook dejó de dispararse, una API devuelve 429, un mapping JSON se rompió tras la última actualización, las ejecuciones se apilan en la cola. Hallamos la causa real rápido y lo reparamos, cloud o self-hosted, con un presupuesto fijo antes de tocar tu instancia.
★★★★★Reseñas verificadas en Trustpilot · Agencia de IA, automatización y growth
Activecampaign
Adalo
AdCreative.ai
Agencia Hermes Agent
Ahref
Airtable
Allo-The-Mobile-First-Company
Anthropic
Apify
Apolloio
Attio
Base44
Baserow
Brevo
Bright-Data
Browse-Ai
Bubble
Captaindata
ChatGPT
Claude
Claude CodeClaude CoworkClaude Design
Clay
Clickup
Cursor
DeepSeek
Depuración Make
Depuración n8n
Depuración Zapier
Dust
ElevenLabs
Fillout
Flutterflow
Folk-Crm
Freepik SpacesLa depuración de n8n es más que reiniciar el workflow.
Cualquiera sabe desactivar y reactivar un workflow. Encontrar por qué se rompió, repararlo para que sobreviva al input que lo tumbó, y frenar el próximo fallo silencioso es otro trabajo. Estas son las cuatro cosas que asumimos.
- Diagnóstico
Encontramos la causa, no solo el síntoma
Un nodo en rojo es el síntoma, no la causa. Leemos tus Executions, aislamos el nodo exacto que falló, miramos el input y el output reales que lo rompieron, y lo rastreamos hacia atrás. La mayoría de los bugs de n8n vienen de una lista corta: un token OAuth expirado, una API externa que cambió su JSON, un nodo deprecated tras una actualización de n8n, un webhook bloqueado aguas arriba. Encontrarlo solo lleva horas. Nosotros ya hemos visto el patrón.
Describir mi bug - Reparación y solidez
Lo reparamos y hacemos que deje de romperse
Arreglar el crash es la mitad del trabajo. Sustituimos las expresiones frágiles por accesos defensivos, añadimos try/catch y una retry policy, pasamos los bucles síncronos a Split In Batches, y cableamos un Error Workflow para que el próximo fallo avise por Slack en vez de morir en silencio. No recuperas solo un workflow que funciona, recuperas uno que aguanta el input que lo había roto.
Ver el método - Reconstrucción y migración
El workflow legacy que ya nadie entiende
La mitad de los workflows que tocamos los construyó un freelance que ya no está, un compañero que dejó la empresa, o tú mismo a las 2 de la madrugada. Lo leemos, lo entendemos, lo reparamos. Si la estructura es demasiado frágil para parchear, lo decimos y cotizamos una reconstrucción limpia en vez de apilar hacks. Igual con las migraciones Zapier a n8n o Make a n8n que se rompieron por el camino.
Hablar de reconstrucción - Prevención y monitoreo
Para que el apagón de las 9h no vuelva
Los peores fallos de n8n son los silenciosos: el workflow parado desde hace 3 días que nadie vio, hasta que un cliente lo notó. Montamos un Error Workflow que captura los fallos con su contexto, un camino de reintento para errores pasajeros como un HTTP 429, y alertas que saltan antes de que tu negocio lo note. Opcional, pero en un workflow crítico se amortiza en el primer rescate.
Ver el monitoreo
Mientras buscas en los logs, tu negocio espera.
Un workflow crítico caído no se mide en horas de dev. Se mide en tratos que se escapan, leads que se evaporan, y un equipo que vuelve en silencio a la entrada manual. El error clásico: depurarlo tú mismo durante tres días, empeorarlo tocando nodos que no dominas, y luego llamar a alguien en pánico el cuarto día, cuando el coste operativo ya superó el de una reparación limpia el primer día.
- Diagnóstico · leemos las Executions, aislamos el nodo que falla, encontramos la causa real
- Presupuesto · un precio fijo para la reparación antes de tocar nada, sin contador por horas
- Reparación · código defensivo, batches, reintentos, probado con los payloads que lo rompieron
- Refuerzo · un Error Workflow y alertas para que el próximo fallo no sea silencioso
Vivimos n8n a diario, no solo en la urgencia.
Construimos y operamos n8n en los stacks de clientes cada semana: HubSpot, Pipedrive, Salesforce, Stripe, Airtable, Notion, OpenAI, Claude. Cada integración tiene sus trampas y las conocemos. Así que cuando describes un bug, en la mayoría de los casos ya lo hemos cruzado en otro sitio. Esa es la diferencia con alguien que descubre tu stack en el peor momento.
- Vivimos n8n a diario en los stacks de clientes, así que cuando describes un bug, lo más probable es que ya lo hayamos visto en otro sitio.
- Presupuesto fijo antes de tocar tu instancia. Conoces el coste de antemano, sin contador por horas que se dispara.
- Te quedas autónomo: la reparación llega con un informe breve de qué se rompió, por qué, y qué cambió.
- Ningún badge que vender. Nos juzgan por si tu workflow funciona tras irnos, no por un nivel de partner.
Seis familias de bugs de n8n, y cómo las leemos.
Cada familia tiene sus señales de alerta y su camino de diagnóstico. Si reconoces tu problema aquí, es porque lo hemos resuelto más de una vez.
- Modo de fallo
Errores de ejecución
El workflow se congela a medio run, el nodo HTTP da timeout a los 30s, el mismo nodo crashea en bucle. Suele ser una retry policy ausente, una ejecución síncrona sobre 10.000+ items, o una cola Redis saturada en self-hosted.
- Modo de fallo
Bugs de integración
Webhook que ya no dispara, OAuth que se invalida cada 24h, una integración que funcionaba desde hace 8 meses y se para. Token no refrescado, firma de webhook cambiada aguas arriba, o endpoint API deprecated que n8n no ha alcanzado.
- Modo de fallo
Errores de datos
«Cannot read property of undefined» en una expresión, un campo siempre presente que se vuelve null, la API que cambia su estructura JSON. Sustituimos los mappings frágiles por accesos defensivos y validamos los payloads aguas arriba.
- Modo de fallo
Rendimiento
Un workflow que tardaba 3 minutos ahora tarda 25, el servidor hace swap, las ejecuciones se apilan, «JavaScript heap out of memory» en los logs Docker. Lo perfilamos, y pasamos a Split In Batches y paginación cursor-based.
- Modo de fallo
Self-hosted y Docker
Una actualización de versión de n8n rompió la mitad de tus workflows, la instancia crashea cada pocas horas, las credenciales desaparecen tras un reboot. Breaking change en un nodo, N8N_ENCRYPTION_KEY ausente, o volumen Docker mal montado.
- Modo de fallo
Webhooks en concreto
URL de test usada en producción, un workflow inactivo, una regla de Cloudflare o firewall que bloquea, ejecuciones duplicadas porque el workflow responde demasiado lento. Probamos con un payload manual y rastreamos toda la cadena.
Describe el bug, volvemos con una primera lectura.
Sin tarifa estándar, sin presupuesto genérico. Nos envías los detalles del workflow que falla, miramos, y te decimos qué podemos hacer. Un Loom de 3 minutos o un screenshot del log de error basta para empezar. Recibes una respuesta clara y un presupuesto fijo antes de que nadie toque tu n8n.
- Qué falla y por qué, en lenguaje claro
- Más o menos cuánto trabajo lleva la reparación
- Un presupuesto fijo antes de tocar tu instancia
- Una opinión honesta si puedes repararlo tú mismo
Del mensaje de pánico a una reparación que aguanta.
Cinco pasos, en orden. No reparamos antes de encontrar la causa, no tocamos tu instancia antes de que apruebes el presupuesto, y entregamos las llaves a tu equipo al final. Cada paso tiene un entregable.
- Paso 1 · Diagnóstico flash
Envía un Loom de 3 minutos o el log de error
Nos envías un Loom corto o un screenshot de la Execution que falla. Conseguimos acceso de lectura a tu n8n (o trabajamos por screen-share si estás bajo NDA), leemos las Executions, aislamos el nodo que se rompió, y fijamos la causa raíz. Recibes una respuesta clara: qué falla, por qué, y más o menos cuánto trabajo lleva la reparación. Sin volcado de jerga, sin informe de 40 páginas.
- Paso 2 · Presupuesto fijo primero
Un precio fijo antes de tocar nada
Una vez conocida la causa, cotizamos un alcance fijo para la reparación. Sin contador por horas, sin rango vago que se infla después. Lo apruebas o no. Si prefieres repararlo tú mismo con nuestro diagnóstico en mano, es tu decisión, sin problema. Nada se mueve en tu instancia hasta que dices que sí.
- Paso 3 · Reparación y pruebas
Lo reparamos y lo probamos con payloads reales
Lo corregimos en tu n8n, o vía pull request si trabajas con workflows en Git. Luego probamos con datos reales, reproduciendo los inputs exactos que lo rompieron más unos cuantos casos límite, y relanzamos varias ejecuciones para confirmar que es estable, no solo verde una vez. Expresiones defensivas, batches, reintentos: la reparación se construye para sobrevivir al input que lo rompió.
- Paso 4 · Blindar contra el próximo
Frenar el fallo silencioso antes de que empiece
Un workflow que se rompe en silencio es peor que uno claramente caído. Cableamos un Error Workflow que captura los fallos con su contexto, qué nodo, qué input, a qué hora, y enruta una alerta a Slack o email. Para errores pasajeros como un rate-limit 429, añadimos un camino de reintento para que un bache no se convierta en un apagón. Opcional, pero ahí está la mayor parte del valor.
- Paso 5 · Traspaso
Te damos las llaves, no una dependencia
Te explicamos en 15 minutos qué cambiamos, qué vigilar, y dos o tres cosas que hacer para que no vuelva. La reparación llega con un informe breve. Si prefieres aprender a gestionarlo tú mismo, nuestro curso de n8n cubre el build, la API y un módulo de depuración. Si quieres tenernos disponibles para lo que crece después, lo hablamos aparte.
Nos juzgan por si funciona tras irnos.
Ningún badge de partner que agitar, así que lideramos con lo que importa: los comentarios de los equipos a quienes desbloqueamos los workflows, y si la reparación aguantó una vez que nos fuimos. Nuestras reseñas de Trustpilot vienen de esos operadores, no de un deck de marketing.
- Cada reparación llega con un informe breve de qué cambió
- Probamos con los payloads exactos que rompieron el workflow
- Un Error Workflow para que el próximo fallo no sea silencioso
- Las reseñas de Trustpilot vienen de los equipos que desbloqueamos
Las preguntas que nos hacen en bucle.
¿Cómo funciona el precio de una reparación de n8n?
Sin contador por horas sorpresa. Nos describes el bug, miramos el workflow, y te enviamos un presupuesto fijo según lo que implica la reparación. Lo apruebas o no. Si prefieres repararlo tú mismo con nuestro diagnóstico, perfecto. Para necesidades recurrentes (workflows críticos, monitoreo, soporte continuo) montamos un formato aparte en vez de una reparación puntual. La primera revisión que encuadra el problema no te compromete a nada.¿Gestionáis urgencias que bloquean el negocio?
Sí, es una gran parte de lo que vemos. Si un workflow crítico bloquea la facturación, los leads o la entrega, lo priorizamos. Envía un mensaje claro: qué está roto, desde cuándo, y el impacto de negocio. La rapidez con que lo cogemos depende de la complejidad y de la disponibilidad del equipo cuando escribes, así que no prometemos un plazo fijo que no podríamos cumplir. Preferimos ser honestos a darte un número de horas y fallarlo.¿Trabajáis en n8n cloud o self-hosted?
Ambos. n8n cloud (los planes de pago de n8n.io), self-hosted en Docker, self-hosted en Kubernetes, y queue mode con Redis. Para self-hosted también podemos auditar la infra alrededor del workflow: variables de entorno como N8N_ENCRYPTION_KEY y WEBHOOK_URL, healthchecks, backups, y subidas de versión. Muchos de los bugs más retorcidos que vemos son a nivel de infra, no de workflow, y solo aparecen bajo carga o tras un reboot.¿Cómo accedéis a mi instancia de n8n?
Tres opciones. Una, creas un usuario de lectura (o de edición si hay reparación prevista) y entramos con credenciales dedicadas. Dos, trabajamos por screen-share en Loom o Zoom, tú conduces y nosotros guiamos, así mantienes el control total. Tres, para workflows sensibles firmamos un NDA antes de cualquier acceso. La mayoría de equipos eligen la opción uno para una reparación y la dos cuando el dato es sensible. Eliges tú, no nosotros.Mi webhook de n8n dejó de dispararse, ¿es recuperable?
Casi siempre. Los sospechosos habituales: la URL del webhook mal configurada en el lado del tercero (Stripe, Typeform, HubSpot), el workflow inactivo en n8n, la URL de test usada en producción, el secreto de firma cambiado, un túnel ngrok caído en self-hosted, o una regla de Cloudflare que bloquea la llamada. Probamos el webhook manualmente con curl o Postman, revisamos las cabeceras y el payload, y recorremos la cadena hasta encontrar dónde muere la llamada.Mi workflow falla de forma aleatoria, ¿lo encontráis igual?
Sí, y es uno de los casos más comunes. Extraemos las Executions de unos cientos de runs y buscamos el patrón: ¿siempre el mismo nodo? ¿Solo ciertos payloads? ¿Horas concretas? Causas típicas: un rate limit que cambia según la hora, una race condition entre dos workflows, o input ocasionalmente mal formado. Una vez encontrado, añadimos un Error Workflow para que te avise la próxima vez en vez de fallar en silencio.¿Reparáis workflows que no construí yo mismo?
Sí, es una gran parte de lo que hacemos. Muchos de los workflows que tocamos vienen heredados de un freelance, de un miembro del equipo que se fue, o de un consultor que ya no está. Leemos el workflow, entendemos la lógica, encontramos el bug. Si la estructura es demasiado frágil para parchear con seguridad, lo decimos y cotizamos una reconstrucción limpia en vez de apilar otro apaño sobre una base inestable.¿Gestionáis migraciones Make a n8n o Zapier a n8n rotas?
Sí, y las migraciones rotas son frecuentes. Reconstruimos el escenario en n8n adaptando la lógica, porque los nodos no se comportan igual, reconectamos tus integraciones, y probamos con tu dataset real antes de la migración. Desde Zapier sueles ganar en coste, desde Make ganas en flexibilidad (lógica condicional, código custom, self-hosting). También retomamos las migraciones a medio hacer que otro empezó y abandonó.Mi workflow va demasiado lento, ¿podéis acelerarlo?
Sí, el rendimiento es una petición recurrente. Los cuellos de botella habituales: llamadas API sin paginar sobre miles de registros, bucles síncronos que hacen N×M peticiones, expresiones JavaScript pesadas, o memoria saturada en self-hosted. Perfilamos la ejecución, encontramos el nodo que consume tiempo y memoria, y refactorizamos a Split In Batches, parallel execution controlada y paginación cursor-based. Los runs grandes que ahogaban la instancia vuelven a un tiempo de ejecución sano.¿Por qué no contratar un freelance de n8n más barato?
Puedes, y para una reparación puntual simple un buen freelance puede costar menos. Las contrapartidas: suele facturar por horas (incertidumbre de presupuesto), ha visto menos casos que un equipo que vive n8n a diario, y no siempre está disponible rápido cuando un workflow crítico cae. Nuestra propuesta: presupuesto fijo antes de la reparación y experiencia acumulada en muchas integraciones. Para una reparación no urgente, el freelance puede ser la opción correcta. Para un workflow que bloquea tu negocio, las cuentas se inclinan hacia nosotros.
Deja de leer logs a las 23h. Envíanos el bug.
Un Loom de 3 minutos o el log de error. Volvemos con una primera lectura y un presupuesto fijo antes de tocar tu n8n. Si tu equipo puede repararlo con nuestro diagnóstico, te lo diremos. Si encajamos, lo hacemos nosotros.