Nodo Execution Data n8nConfigura Execution Data en n8n.

Empieza por las alertas. Un flujo que vigila stock y avisa por Slack genera decenas de ejecuciones parecidas. Guardar el SKU y el almacén en cada una convierte el historial en algo consultable: la pregunta ¿cuándo saltó el aviso de este producto? se responde con una búsqueda, no leyendo ejecuciones de arriba abajo.

Segundo escenario, la sincronización nocturna. Un flujo vuelca registros en MySQL cada madrugada. Guardar la fecha del lote y el origen de los datos deja un rastro claro cuando alguien pregunta qué entró y de dónde vino, sin tener que abrir la base para deducirlo.

Tercer escenario, el más ruidoso. Un flujo que arranca con un Webhook recibe llamadas de varios emisores a la vez. Etiquetar cada ejecución con el emisor y el tipo de aviso ordena el historial en grupos que sí se pueden leer cuando un lote falla.

Cuándo elegir otra cosa: este nodo escribe, nunca lee. Recuperar datos de ejecución personalizados mientras el flujo sigue corriendo es tarea del nodo Code. Y si lo que buscas es guardar datos de negocio para informes, el sitio natural es una base de datos. Aquí se ordena para reencontrar, no para analizar. La comparación entre enfoques está en la Reseña n8n.

Conviene conocer los topes antes de diseñar sobre ellos. Una clave llega hasta 50 caracteres y un valor hasta 512. Si alguno se pasa, n8n lo trunca a la longitud máxima y escribe una entrada de log: nada se rompe a la vista, el valor simplemente queda más corto. El nodo tiene una sola operación, se queda en la versión 1 y no abre flujos: un Schedule Trigger, un Webhook o el trigger de una herramienta tiene que arrancar la ejecución antes.