Informe diario de tendencias con n8n: probamos el 2.45

Un flujo de n8n en tu propio equipo puede armar cada mañana un informe de tendencias con EveryInfra por 0,002224 USD por ejecución. Lo difícil no son las llamadas a la API, sino tres cosas: qué pasa con la ejecución que tocaba mientras n8n estaba apagado, por qué una repetición parece cobrada dos veces y cómo evitar que una sola llamada fallida tumbe el informe entero. El 26 de octubre de 2026, de 10:36 a 11:25 hora de Singapur (UTC+8; de 20:36 a 21:25 del 25 de octubre en la Ciudad de México), ejecutamos n8n 2.45.3 cada 3 minutos en una Mac, lo apagamos dos veces a propósito y cotejamos 14 informes con la base de datos, las métricas y nuestro registro de llamadas.

En este artículo, un «informe diario de tendencias» es un flujo de n8n que corre en tu propia máquina. Un nodo Schedule Trigger lo despierta, un nodo Code enumera las listas que hay que leer, un nodo HTTP Request llama a EveryInfra con una sola clave de API y un segundo nodo Code escribe en un archivo Markdown el top 10 de cada lista, cuántos temas siguen respecto a la ejecución anterior y cuánto costó. El informe responde a «de qué se está hablando esta mañana en cada plataforma». No predice qué será tendencia ni verifica si un tema es cierto.

La ilustración resume la idea del planificador durable. Una ejecución ya no es un temporizador dentro de un proceso: es una fila en la base de datos que se escribe antes de que toque, y a su hora un proceso de n8n la reclama y la ejecuta. La documentación de n8n lo divide en cinco etapas: materialización, ejecución, recuperación, retención y conciliación de dueños. En cada prueba de abajo leímos en SQLite las filas reales de esas etapas.

Cómo es un informe

Este es el informe de la ejecución de las 10:39:24 (hora de Singapur). El archivo original salió de la primera versión del paso 5, que también numeraba un puesto promocionado de Weibo; aquí lo regeneramos con las respuestas originales de esa ejecución y el paso 5 corregido (ordena por rank y salta las filas sin puesto). Quitamos algunas filas para acortarlo.

# Informe diario de EveryInfra 2026-10-26T10:39:24.294+08:00

## Tendencias de X en México (71 elementos, $0.000556)
1. Lula
2. Pachuca
3. #EleccionesBrasil2026
5. América Latina
7. México y Brasil

## Tendencias de X en EE. UU. (52 elementos, $0.000556)
1. Lula
2. Brazil

## Lista caliente de Weibo (10 elementos, 2 promocionados omitidos, $0.000556)
4. El presidente de Brasil, Lula, gana la reelección

## Lista de tendencias de Douyin (8 elementos, $0.000556)
5. Lula, reelegido presidente de Brasil

## Nombre de lista mal escrito a propósito: falla (HTTP 422, invalid_value)
- `boards` must be one of: challenge, entertainment, hotspot, seeding, social (got 'hot')

## Coste de esta ejecución
- Suma de charged_usd en las respuestas: $0.002224
- Cargo real sin las repeticiones: $0.002224

Los encabezados están en chino porque el equipo que armó el flujo lo lee en chino; son texto libre dentro del nodo Code y se cambian en una línea. En este archivo hay dos cosas que vale la pena mirar.

La primera es que un mismo hecho encabezó cuatro listas a la vez. Brasil celebró el 25 de octubre la segunda vuelta de su elección presidencial (aviso del Tribunal Superior Electoral). Esa noche, a las 20:39 en la Ciudad de México, «Lula» era el número 1 de las tendencias de X en México y en EE. UU., y la misma noticia ocupaba el puesto 4 en Weibo y el 5 en la lista de temas calientes de Douyin, en China. El puesto de Weibo merece una nota: la cuarta fila de la respuesta era una campaña de marca sin campo rank, un puesto promocionado (las reglas de la lista caliente de Weibo incluyen los anuncios comerciales como un tipo de etiqueta), y la fila de Lula tenía rank 4. Nuestro primer nodo del informe numeraba por posición, así que puso a Lula en el 5 y metió el anuncio como tema caliente; el paso 5 ahora ordena por rank, salta las filas sin puesto y dice en el encabezado cuántas saltó. En México, además, la conversación se leía en clave regional: «#EleccionesBrasil2026», «América Latina», «México y Brasil» y «Latinoamérica» aparecían en el mismo top 10, junto con el fútbol («Pachuca»). Un informe que cruza plataformas sirve justamente para ver de un vistazo cuándo China, EE. UU. y México hablan de lo mismo.

La segunda es que la llamada fallida no hizo fallar el informe: aparece como una nota breve con el motivo y el valor sugerido, y la sección de costos deja claro que no se cobró. La prueba 4 explica por qué conviene diseñarlo así desde el principio y no después del primer error.

Los criterios que fijamos antes de empezar

Antes de la primera ejecución escribimos 10 criterios de aprobación en nuestro registro de verificación y no los cambiamos al ver los resultados. Hubo una sola excepción. Pensábamos verificar los cobros con el saldo de la cuenta, pero a las 10:33 (hora de Singapur) vimos que otros redactores usaban la misma clave de prueba, así que el saldo también se movía con sus llamadas. Antes de cualquier llamada cobrada, cambiamos el método: buscar cada request_id en el registro de llamadas del servidor.

Los problemas más difíciles de una tarea programada no aparecen como errores (falta una ejecución, otra se repite, un cobro sale un poco más alto), así que los criterios fijan de antemano cuántas, cuántas filas y cuánto dinero. Un usuario de n8n contó que cuando un nodo recibe cero elementos, los nodos siguientes no se ejecutan, pero la ejecución sigue marcada como correcta y el flujo de errores nunca arranca (hilo en Reddit r/n8n). Ese tipo de problema solo se detecta si antes anotas cuántas ejecuciones, cuántas filas y cuánto dinero esperas.

Antes de empezar: versión, forma de instalación y Node.js

Versión. El planificador durable viene activado por defecto desde n8n 2.45.0, publicado el 20 de octubre de 2026; el registro de cambios dice que los nodos Schedule Trigger «now run on the durable scheduler by default». Pero el 26 de octubre el registro de npm todavía tenía la 2.44.6 (del 22 de octubre) bajo la etiqueta latest, y la 2.45.3 (del 23 de octubre) bajo next y beta. Es decir, si hoy ejecutas npm install n8n a secas, recibes la 2.44.6, donde el planificador durable sigue apagado por defecto. Para repetir esta prueba tienes que indicar la versión. n8n además parchea las dos líneas por separado: la actualización de seguridad del 14 de octubre dice «beta patched in v2.44.1» y «stable patched in v2.43.5».

Entre el 13 y el 23 de octubre, las líneas 2.44 y 2.45 sacaron entre las dos 7 versiones en npm (de la 2.44.0 a la 2.45.3) y se turnaron con los parches. Si instalas «la última versión» siguiendo un tutorial, puedes acabar en cualquiera de las dos.

Forma de instalación. Usamos npm porque esta Mac tiene Node.js y no tiene Docker. Hay dos costos que conviene conocer. El primero: la página de instalación con npm ya avisa que «npm-based installs are deprecated from n8n 3.0», y la página de cambios incompatibles de la 3.0 es más directa: la 3.0 exige Docker y npm dejará de recibir un paquete n8n ejecutable. La guía de desarrollo de n8n en GitHub sitúa la v3 hacia octubre de 2026, y nuestro propio n8n lo recordó al arrancar con la advertencia «Running n8n outside a container is deprecated».

Por eso npm sirve para probar en un portátil; para un informe que va a correr todos los días durante meses, usa Docker Compose o la instalación en una línea.

El segundo costo es el tamaño. Una instalación limpia añadió 2328 paquetes en 6 minutos y node_modules ocupó 4,4 GB. Nuestra primera instalación se cortó a la mitad; la carpeta a medio instalar falló al arrancar con Cannot find module 'kuler', y un segundo npm install en la misma carpeta no lo arregló. Borramos node_modules y package-lock.json, instalamos de nuevo y n8n arrancó. Si una instalación se interrumpe, empieza desde una carpeta vacía: es lo más rápido.

Versión de Node.js. Aquí la documentación y el paquete no coinciden. La página de npm habla de «between 20.19 and 24.x», mientras que el propio paquete (npm view n8n@'2.45.3' engines) pide >=24.0.0. La tabla de versiones de Node.js muestra que la 20 dejó de tener soporte en marzo de 2026, la 24 es LTS y la 26 sigue como «Current». Usamos la 26.11.1 sin problemas en esta prueba, pero eso queda fuera del rango documentado; para un informe de larga duración, usa Node.js 24 LTS.

Queda una trampa más: el puerto. Primero pusimos n8n en el 5679 y se cerró de inmediato con una sola línea en el registro: «n8n Task Broker's port 5679 is already in use». En n8n 2.x los nodos Code se ejecutan en un ejecutor de tareas integrado cuyo intermediario usa justamente el puerto 5679. Movimos N8N_PORT al 5690, fijamos N8N_RUNNERS_BROKER_PORT en 5691 y n8n arrancó. Esta es toda la configuración que usamos:

export N8N_USER_FOLDER=$HOME/Downloads/n8n-lf25/home      # base de datos y clave de cifrado
export N8N_PORT=5690 N8N_LISTEN_ADDRESS=127.0.0.1          # escuchar solo en esta máquina
export N8N_RUNNERS_BROKER_PORT=5691                        # lejos del 5679 del intermediario
export GENERIC_TIMEZONE=Asia/Singapore TZ=Asia/Singapore   # por defecto es America/New_York
export N8N_RESTRICT_FILE_ACCESS_TO=$HOME/Downloads/n8n-lf25/reports
export N8N_DIAGNOSTICS_ENABLED=false N8N_VERSION_NOTIFICATIONS_ENABLED=false
export N8N_METRICS=true N8N_METRICS_INCLUDE_SCHEDULER_METRICS=true
npm install [email protected] --no-audit --no-fund

Los mismos ajustes en una tabla, con el motivo de cada uno:

La dirección de escucha es 127.0.0.1 para que solo esta máquina pueda abrir n8n. Censys, una empresa que escanea internet, contó en su informe anual del 14 de octubre 113.926 instalaciones de n8n en la internet pública, y el 76 % de las que muestran su versión tenía al menos una vulnerabilidad crítica reciente (blog de Censys); n8n publica actualizaciones de seguridad cada dos semanas (por ejemplo, la del 1 de octubre). Si quieres leer los informes desde otro equipo, sincroniza la carpeta reports/; no abras el editor de n8n a internet.

No te saltes la línea de la zona horaria. La página de zona horaria explica que una instancia propia usa America/New_York por defecto y que el Schedule Trigger se basa en ella para saber de qué «8 de la mañana» hablas. También puedes fijar la zona en los ajustes de cada flujo; nosotros pusimos Asia/Singapore en los dos sitios. La línea de archivos importa igual: desde n8n 2.0, el nodo Read/Write Files solo puede usar ~/.n8n-files por defecto. Para guardar los informes en otra carpeta hay que permitirla con N8N_RESTRICT_FILE_ACCESS_TO, y conviene permitir solo esa.

Si tu informe va en hora de México

México tiene una ventaja para este tipo de tareas: desde 2022 la mayor parte del país ya no cambia la hora. La Ley de los Husos Horarios en los Estados Unidos Mexicanos, publicada en el Diario Oficial de la Federación el 28 de octubre de 2022, fija un horario estándar por zonas (Centro, Pacífico, Noroeste y Sureste) y deja el horario estacional solo para los estados y municipios de la frontera norte (artículos 4 y 5). Para un informe con America/Mexico_City, las 8:00 son siempre las 8:00 y nunca vas a tener una hora repetida ni una hora que no existe.

La excepción es la frontera. Baja California, Ciudad Juárez, Nuevo Laredo, Reynosa, Matamoros y los demás municipios que enumera el artículo 5 siguen el cambio de horario de EE. UU., que en 2026 termina el 1 de noviembre a las 2 de la mañana, hora local, según el NIST. Si tu equipo está en Tijuana o en Juárez, usa el nombre correcto de la base de zonas horarias de la IANA (America/Tijuana, America/Ciudad_Juarez, America/Matamoros) y no un desfase fijo como UTC−6. Y no programes el informe entre la 1 y las 3 de la madrugada: el 1 de noviembre esa franja existe dos veces.

Esta tabla resume qué pasa el 1 de noviembre en las zonas más usadas, según la ley y las reglas del NIST:

La documentación del planificador durable dice que las programaciones por horas, días, semanas y meses se disparan igual que antes «in everyday use», y que además resuelve mejor que el planificador en memoria los cambios de horario, los años bisiestos y la semana 53, casos en los que el anterior «could be off by one period». No probamos un cambio de hora real porque el próximo es dentro de una semana.

Armar el flujo: seis nodos, una acción por paso

El flujo tiene seis nodos. Esta animación recorre una ejecución.

No armamos el flujo con clics en el editor: lo escribimos en JSON y lo importamos con la línea de comandos de n8n. Así cada paso se puede repetir tal cual y no hace falta crear una cuenta de propietario en tu n8n local. En cada paso damos la acción, lo que deberías ver y el porqué.

1. Guarda la clave de API como credencial de n8n. Ejecuta jq -n --arg t "$EVERYINFRA_API_KEY" '[{"id":"eiBearer000001","name":"EveryInfra API Key","type":"httpBearerAuth","data":{"token":$t}}]' | n8n import:credentials --input=/dev/stdin. Deberías ver «Successfully imported 1 credential».

Lo importante es --input=/dev/stdin: la clave pasa solo por una variable de entorno y una tubería, nunca por un archivo. Cuando el campo data llega en texto plano, el comando de importación lo cifra con la clave de la instancia antes de escribirlo (en el código fuente es cipher.encryptV2). Si en cambio escribes la clave en una cabecera del nodo HTTP Request, queda en texto plano dentro del JSON del flujo, de cada exportación y del historial de versiones. La página de credenciales de HTTP Request ofrece Bearer, Header y otros tipos; usa Bearer, que envía la cabecera Authorization: Bearer del RFC 6750, el formato que espera EveryInfra.

1. Añade un Schedule Trigger. Para la prueba, «cada 3 minutos»; para el uso diario, «Days», 8 a. m., minuto 0. Al publicar aparece una fila nueva en la tabla scheduled_job de SQLite, con intervalSeconds 180, misfirePolicy skip y misfireGraceSeconds 60.

La página del Schedule Trigger trae dos ajustes nuevos. «If Execution Is Missed» tiene tres opciones y por defecto descarta. «Missed Execution Grace Period (Seconds)», si lo dejas en 0, usa el valor de la instancia, N8N_SCHEDULER_MISFIRE_GRACE, que por defecto es 60 segundos. Los dos solo valen para nodos añadidos desde la 2.36 y solo con el planificador durable encendido. Revisamos el código del nodo para saber qué valor se guarda: coalesce_owner es «Run the Most Recent Missed Execution», coalesce es lo mismo pero por regla y skip es el valor por defecto.

1. Enumera las peticiones en un nodo Code, cada una con su clave. El nodo devuelve 5 elementos con la plataforma, la acción, los parámetros y un campo idem. Deberías ver 5 elementos de salida.

const now = DateTime.now().setZone('Asia/Singapore');
// Uso diario: una clave por día (repetir el mismo día es una repetición, no un cobro nuevo). Prueba: una por minuto.
const KEY_BY = 'day';
const keyBase = KEY_BY === 'day' ? now.toFormat('yyyyLLdd') : now.toFormat('yyyyLLdd-HHmm');
const reqs = [
  { label: 'Lista caliente de Weibo', platform: 'weibo', action: 'trending', params: {} },
  { label: 'Tendencias de Douyin', platform: 'douyin', action: 'trending', params: { boards: 'hotspot' } },
  { label: 'Tendencias de X en EE. UU.', platform: 'twitter', action: 'trending', params: { country: 'us' } },
  { label: 'Tendencias de X en México', platform: 'twitter', action: 'trending', params: { country: 'mx' } },
  { label: 'Lista mal escrita', platform: 'douyin', action: 'trending', params: { boards: 'hot' } },
];
return reqs.map(r => ({ json: { ...r,
  idem: `daily-report-${keyBase}-${r.platform}-${r.params.country || r.params.boards || 'default'}`,
  firedAt: now.toISO() } }));

Es exactamente el código que ejecutamos; solo traducimos el comentario. Las etiquetas están en chino y puedes cambiarlas sin tocar nada más.

¿Por qué generar tu propia clave? Porque un informe diario no debería correr dos veces, cobrarse dos veces y dejar dos archivos distintos el mismo día. La descripción OpenAPI de EveryInfra dice que una llamada síncrona con la misma Idempotency-Key, plataforma, acción y parámetros dentro de 24 horas «replays the first successful response»: no se vuelve a ejecutar ni a cobrar. Con la misma clave y otros parámetros, la respuesta es 409 idempotency_conflict. Una clave construida con la fecha le dice a la API «solo quiero una copia de la lista de hoy». El patrón es el mismo que el del borrador de la IETF para la cabecera Idempotency-Key, que pasó a la versión 08 el 22 de octubre de 2026. En la prueba pusimos KEY_BY en minute: con una clave por día, todas las ejecuciones de cada 3 minutos después de la primera habrían sido repeticiones y no habríamos visto cómo cambian las listas.

1. Llama a EveryInfra con un nodo HTTP Request. Método POST, URL https://api.everyinfra.com/api/v1/social, credencial Bearer del paso 1, cabecera Idempotency-Key: {{ $json.idem }} y cuerpo JSON {{ JSON.stringify({ platform: $json.platform, action: $json.action, params: $json.params }) }}. En las opciones, activa «Include Response Headers and Status» y «Never Error», y pon lotes de 1 elemento con 1500 ms entre lotes. Deberías ver 5 elementos por ejecución: 4 con statusCode 200 y 1 con 422.

«Never Error» es el interruptor más importante de este paso. La página de HTTP Request explica que, por defecto, una respuesta que no es 2xx hace fallar el nodo: la ejecución se detiene ahí y el nodo del informe nunca corre. Un informe diario necesita lo contrario: si una lista falla, las demás entran igual y la que falló queda anotada. Con «Never Error» y la respuesta completa, el cuerpo y el estado del 422 pasan al siguiente nodo como datos normales. El intervalo entre lotes te mantiene por debajo del límite de EveryInfra de 10 llamadas por minuto por clave (GET /api/v1/account lo devuelve como key_requests_per_minute). Con 1,5 segundos entre llamadas, cada ejecución tardó entre 13 y 16 segundos.

1. Escribe el informe en un segundo nodo Code y recuerda la ejecución anterior. El nodo empareja en orden las 5 respuestas con las 5 peticiones del paso 3, toma el top 10 de cada lista por rank y salta las filas promocionadas sin puesto (ver el código de abajo), lee el top 10 anterior con $getWorkflowStaticData('global'), cuenta las coincidencias y guarda las listas nuevas. Deberías ver un elemento con markdown y fileName.

El paso del top 10 hay que escribirlo bien. La respuesta de Weibo mezcla puestos promocionados: tienen título y valor de calor, pero no rank. En nuestras 14 ejecuciones, los puestos promocionados ocuparon 16 de las primeras 10 posiciones de Weibo en total; Douyin y X no tuvieron ninguno. Si numeras por posición, un anuncio pasa por tema caliente y todos los puestos siguientes se corren uno. Pon esto en el segundo nodo Code: si alguna fila de la lista tiene rank, quédate solo con las que lo tienen y ordénalas; usa la posición solo cuando ninguna fila tenga puesto.

function top10(results) {
  const rows = results || [];
  const hasRank = rows.some(x => x.rank != null);
  const kept = hasRank ? rows.filter(x => x.rank != null).sort((a, b) => a.rank - b.rank) : rows;
  return {
    top: kept.slice(0, 10).map((x, i) => ({ rank: x.rank ?? i + 1, title: x.title || x.keyword || x.name })),
    promoted: rows.length - kept.length,   // va al encabezado: «N filas promocionadas saltadas»
  };
}

Estos son los 7 puestos promocionados que aparecieron en las 14 ejecuciones. Solo ocuparon dos posiciones: la 4.ª y la 8.ª. Sus títulos parecen temas calientes normales, así que solo el rank vacío los delata. El último, «varias cremas de ojos acusadas de publicidad engañosa», parece una noticia, pero tampoco trae rank, así que también lo saltamos; si quieres conservar filas así, necesitas otra regla.

Los datos estáticos son la memoria más ligera entre ejecuciones de n8n, pero la documentación pone dos límites: no se guardan en las pruebas manuales, solo cuando un flujo publicado arranca desde un disparador, y pueden fallar con ejecuciones muy frecuentes. Por eso, en una ejecución manual, «coincidencias con la anterior» siempre sale vacío, y es lo esperado. Si necesitas conservar esos datos, la documentación recomienda las tablas de datos. Este nodo también calcula el costo de dos maneras: «suma de respuestas» junta el billing.charged_usd de todas las llamadas y «cobro real» deja fuera las que tienen replayed en verdadero. La prueba 3 explica por qué hacen falta las dos cifras.

1. Convierte a archivo y guárdalo. Usa Convert to File con «Convert to Text File» sobre el campo markdown y escribe el resultado en la carpeta reports/ con el nodo Read/Write Files. Deberías ver un archivo report-<hora>.md nuevo por ejecución.

Si este paso dice que la ruta no se puede escribir o no está permitida, revisa primero N8N_RESTRICT_FILE_ACCESS_TO: la ruta tiene que estar dentro de la carpeta que permite.

1. Publica y reinicia n8n. Ejecuta n8n import:workflow --input=A.json, después n8n publish:workflow --id=eiDailyReport01 y por último n8n start. El registro de arranque debería mostrar «Scheduler started» y «Processed 0 draft workflows, 2 published workflows».

Publicar por línea de comandos tiene un detalle fácil de pasar por alto: publish:workflow escribe directamente en la base de datos, y el propio comando avisa «Changes will not take effect if n8n is running». Un n8n en marcha tiene que reiniciarse para ver el cambio. Ese detalle decide la respuesta de la prueba 1.

Prueba 1: ¿es puntual y desde cuándo cuenta «cada N minutos»?

La 2.45 cambia el significado de «cada N minutos». La página del planificador durable dice que esas programaciones «run at uniform intervals measured from workflow publication», es decir, ya no se alinean con los minutos enteros; para conservar el comportamiento anterior hay que poner N8N_SCHEDULER_TRIGGER_NODE_MODE=legacy. Este es el texto original, con la regla en un recuadro verde azulado.

Entonces, ¿qué momento es «la publicación»? Publicamos los dos flujos por línea de comandos a las 10:32:59 y 10:33:01 (hora de Singapur). n8n arrancó a las 10:36:20 y los activó a las 10:36:24. La tabla scheduled_job de SQLite lo aclara: las dos filas tienen createdAt en 10:36:24.207 y 10:36:24.209, y el primer nextRunAt es 10:39:24.206. La cuenta empieza cuando un n8n en marcha activa el flujo, no cuando el comando escribe en la base. En el editor, las dos cosas ocurren en el mismo clic; por línea de comandos, en nuestra prueba, quedaron separadas por 3 minutos y 25 segundos.

Las 14 ejecuciones cayeron todas en la misma fase: 24,206 segundos después de cada marca de 3 minutos, de 10:39:24 a 11:24:24. En marcha normal, la ejecución empezó entre 0,008 y 0,034 segundos después de la hora prevista, muy por debajo de nuestro umbral de 5 segundos, y cuando no hubo parada de por medio, el intervalo entre dos ejecuciones fue de 179,978 a 180,013 segundos. Reiniciamos n8n dos veces durante la prueba y la fase no cambió: después de cada reinicio, la fila de scheduled_job seguía allí y nextRunAt continuaba con la fase anterior. Un reinicio no empieza una cuenta nueva, y esa es la diferencia más visible con el planificador en memoria.

Esta tabla muestra una por una las 16 horas previstas. Todos los valores salen de SQLite y de los datos de ejecución, y los calcula nuestro script de análisis analysis.py; las horas son de Singapur.

La última columna deja ver algo que no tiene que ver con la programación: en la primera ejecución, Weibo devolvió solo 10 filas y Douyin solo 8; después, las dos devolvieron casi siempre 20, que es el default_limit de ambas en el catálogo. La prueba 3 explica qué implica esto para el costo.

¿Qué significa esto para un informe diario? Si lo quieres a las 8:00 en punto, usa el intervalo «Days» con 8 a. m. y minuto 0: según la documentación, las programaciones por horas, días, semanas y meses se comportan igual en los dos modos. Solo cambian «cada N minutos» y «cada N segundos». Si usabas «cada 30 minutos» para correr a las :00 y a las :30, desde la 2.45 correrá cada 30 minutos a partir del segundo en que activaste el flujo. Para mantener la alineación con la hora entera usa una expresión cron, por ejemplo 0 */30 * * * *, que según la documentación no depende de este ajuste. También puedes poner legacy, pero está marcado como obsoleto y una versión futura lo quitará.

Prueba 2: ¿adónde va una ejecución cuando n8n está apagado?

Es el cambio más grande de la 2.45 y la prueba a la que dedicamos más tiempo. El planificador en memoria guarda la próxima ejecución dentro del proceso, y la documentación lo dice sin rodeos: «Restarts lose pending runs». Lo que toque durante la parada se salta. El planificador durable escribe antes cada ejecución en la base de datos, así que una ejecución perdida «stays on record»: si n8n vuelve dentro de la gracia, sale tarde; si vuelve después, decide la política de ejecuciones perdidas.

Para comparar dos políticas con la misma parada, publicamos dos flujos. El flujo A es el informe, con la política por defecto «Don't Run Missed Executions». El flujo B es un latido: no llama a ninguna API, solo escribe la hora en un archivo y no cuesta nada; usa «Run the Most Recent Missed Execution». Los dos corren cada 3 minutos con la misma fase. Un script detuvo n8n con SIGTERM usando el número de proceso, esperó a que saliera, lo arrancó de nuevo a una hora fija y anotó cada momento.

Primera parada: 32 segundos, dentro de la gracia. Detuvimos n8n a las 10:45:12 (hora de Singapur), lo arrancamos a las 10:45:40 y estaba listo a las 10:45:44. La hora prevista 10:45:24 quedó en medio. La ejecución ya estaba en la tabla scheduled_task antes de la parada: la ventana de materialización, N8N_SCHEDULER_MATERIALIZATION_WINDOW, es de 60 segundos por defecto, así que cada ejecución tiene su fila un minuto antes. Tras el reinicio, A y B empezaron a las 10:45:46,0, con 21,8 segundos de retraso y dentro de los 60 segundos de gracia. Un detalle: antes de la parada, missedAfter de las dos filas era 10:46:24,206 (la hora prevista más 60 segundos); después del reinicio, n8n lo cambió a 10:46:45,677. Parece que el reinicio dio una gracia nueva a partir del arranque. Solo lo vimos una vez y no probamos la regla a fondo.

Segunda parada: 6 minutos y 44 segundos, sobre dos horas previstas. Detuvimos n8n a las 10:49:00, lo arrancamos a las 10:55:40 y estaba listo a las 10:55:44. Las horas previstas 10:51:24 y 10:54:24 cayeron en la parada, y las dos habían superado su gracia de 60 segundos cuando n8n volvió. El resultado coincidió con la documentación: A no corrió ninguna de las dos veces y su siguiente ejecución fue a las 10:57:24. B corrió una vez, a las 10:55:53; esa ejecución corresponde a la hora prevista 10:54:24, la más reciente, con 89,0 segundos de retraso. B no recuperó por separado la de las 10:51:24.

Los datos de ejecución no bastan, porque una ejecución que falta simplemente no aparece. Por eso activamos las métricas de Prometheus de n8n y leímos /metrics una vez, a las 10:56:30, después del segundo reinicio. Los contadores empiezan en cero al arrancar el proceso, así que solo reflejan la segunda parada.

Los intervalos entre ejecuciones del informe muestran las dos paradas con claridad. La primera retrasó una ejecución 21,8 segundos, así que los intervalos de antes y de después quedaron en 201,8 y 158,2 segundos; juntos siguen sumando 360, de modo que la fase no se movió. La segunda descartó dos ejecuciones, y ese intervalo fue de 540,0 segundos, justo tres periodos.

Tres fuentes cuentan la misma historia: los datos de ejecución, la tabla scheduled_task y las métricas. Por eso damos J4 por cumplido. La página de variables del planificador explica cada contador, y n8n publica un panel de Grafana ya armado. Si otras personas leen tu informe, pon una alerta sobre occurrences_misfired_total: si sube, un día no hubo informe.

¿Qué política conviene para un informe diario? Recomendamos «Run the Most Recent Missed Execution» junto con la clave por fecha del paso 3. Un informe diario necesita una copia por día: después de una parada quieres la de hoy, y si n8n vuelve al día siguiente, la recuperación usa la fecha nueva y una clave nueva, así que obtienes la copia del día nuevo. La política por defecto conviene a tareas que no sirven si llegan tarde, como un latido cada minuto. La gracia, ajústala a tu tiempo de reinicio: la documentación pide que sea mayor que el intervalo del ejecutor y no menor que la ventana de materialización, lo que da 60 segundos con los valores por defecto. Si una actualización con reinicio tarda 3 minutos en tu máquina, pon 300 segundos en el nodo.

Prueba 3: el dinero y la repetición que parece cobrada

Cada ejecución consulta 4 capacidades de tendencias: twitter/trending para México y para EE. UU., weibo/trending y douyin/trending. En el catálogo de EveryInfra, leído a las 10:15 (hora de Singapur), las tres tienen price_usd 0,000556 por llamada. Así que cada ejecución debería costar 4 × 0,000556 = 0,002224 USD. Esta es la respuesta real del catálogo para twitter/trending; los recuadros marcan el precio y el significado de collected_at.

Las 14 ejecuciones costaron exactamente 0,002224 USD sin contar repeticiones: 0,031136 USD en total.

No nos quedamos con lo que dicen las respuestas. Al terminar leímos el registro de llamadas del servidor con GET /portal/api/logs y cotejamos cada request_id: las 56 llamadas cobradas de las 14 ejecuciones estaban en el registro, cada una con cost de 40 créditos, es decir 0,000556 USD, igual que el charged_usd de la respuesta hasta el sexto decimal. Las 14 llamadas que devolvieron 422 no tenían ninguna entrada en el registro de llamadas, o sea, ningún cobro.

La trampa está en la repetición. A las 10:40:46 reenviamos con curl la llamada de Weibo de la ejecución de las 10:39, con la misma clave daily-report-20261026-1039-weibo-default.

La respuesta fue 200, con la cabecera idempotent-replayed: true y replayed: true en el cuerpo. El id era el de la primera llamada, req_a5c69df94c2f4d66; la petición nueva tenía su propio identificador en la cabecera x-request-id, req_7278432b29f64594. El registro del servidor no mostró un segundo cobro. Pero el bloque billing seguía diciendo "charged": true, "charged_usd": 0.000556. El texto de OpenAPI lo explica: una repetición devuelve la primera respuesta guardada, con el «same billing, not run or charged again». O sea, billing describe el primer cobro, no esta llamada.

En un informe diario se ve como en el gráfico de abajo. Pusimos KEY_BY en day y ejecutamos el flujo dos veces a mano con n8n execute; el registro de ejecuciones da como hora de inicio las 10:56:46,565 y las 10:57:04,358. En la segunda, las 4 llamadas fueron repeticiones y el cobro real fue 0 USD; un informe que sume todos los charged_usd, como hacen casi todos los tutoriales, mostraría 0,002224 USD también para la segunda.

Así que suma solo las llamadas donde replayed no es verdadero. Nuestro informe muestra las dos cifras: cuando no coinciden, ese día hubo una reejecución y puedes averiguar quién la lanzó y por qué. También probamos el otro caso: a las 10:40:54 enviamos la misma clave con otros parámetros y la API devolvió 409 idempotency_conflict, con next_steps diciendo «send the new request with a new key. Nothing was charged.» Por eso la clave por fecha tiene que incluir también la plataforma y los parámetros; si no, dos listas distintas del mismo día se bloquean entre sí. Es la razón de que la clave del paso 3 lleve la plataforma y el país.

Cuánto cuesta

Esta es la factura de toda la prueba. Todos los importes son el cobro real sin repeticiones, cotejado con el registro del servidor.

Para tu propio informe, el costo depende de la programación:

Todos los precios salen del price_usd del catálogo, leído el 26 de octubre de 2026 a las 10:15 hora de Singapur. La última fila muestra lo que aporta la clave: por mucho que repitas el mismo día, pagas una vez. Hay otro dato fácil de pasar por alto: las listas de tendencias se cobran por llamada, no por fila. Por los mismos 0,000556 USD, la lista de X en México devolvió 71 filas y las de Weibo y Douyin, 20 cada una (medianas de 14 ejecuciones). Por cada 1000 filas, la diferencia es de 3,6 veces.

El número de filas tampoco es fijo. En la primera ejecución, a las 10:39 (hora de Singapur), Weibo devolvió 10 filas y Douyin 8; en las 13 siguientes, Douyin devolvió siempre 20 y Weibo entre 15 y 20, casi siempre 20. Ese es el default_limit de ambas en el catálogo, y weibo/trending tiene un max_limit de 200. Las reglas de la lista caliente de Weibo describen un top 50 que se actualiza cada minuto, así que con el valor por defecto recibes solo una parte. Nuestro informe usa solo el top 10, de modo que la primera ejecución solo le quitó 2 puestos a Douyin. Si necesitas la lista completa, revisa en el catálogo si se puede pasar limit, confirma el número de filas con una llamada real y anota en el informe cuántas filas trajo cada ejecución; no lo estimes por el valor por defecto. Una respuesta corta cuesta igualmente 0,000556 USD, así que tenlo en cuenta al calcular un precio por fila.

Prueba 4: una llamada mal escrita y el informe llega igual

En cada ejecución, la quinta llamada pone el valor boards de Douyin en hot; el correcto es hotspot. En las 14 ejecuciones, esa llamada devolvió 422, el informe llegó igual y las otras 4 listas estaban completas. Esta es la respuesta real de la ejecución de las 10:39:

¿Por qué esta respuesta encaja bien en una automatización? Porque da el arreglo en campos que un programa puede leer: allowed enumera los valores válidos, did_you_mean da el más cercano, retryable: false avisa que la misma petición volverá a fallar y la primera línea de next_steps dice «Nothing was charged». Nuestro nodo del informe copia message y did_you_mean, así que quien lo lee sabe que debe poner hotspot. El código 422 es «Unprocessable Content» en el RFC 9110: la petición está bien formada, pero su contenido no se puede procesar, de modo que reintentar lo mismo no va a funcionar.

Todo esto funciona gracias a «Never Error» del paso 4. Sin ese interruptor, n8n marca la ejecución como fallida y lanza tu flujo de errores (página de manejo de errores), y ese día no hay informe. Para un archivo que la gente lee a diario, es mucho mejor que falte una lista que el archivo entero. Esta tabla reúne las respuestas que provocamos en la prueba o encontramos en el texto de OpenAPI, y qué debería hacer el informe con cada una.

Los cinco primeros casos los provocamos nosotros. El 401 salió de una llamada sin clave a las 10:18 (hora de Singapur) y conservamos la respuesta cruda archivada. Las dos últimas filas vienen del texto de OpenAPI; no las provocamos en esta prueba.

Prueba 5: la misma capacidad con el nodo MCP Client

n8n también tiene un nodo MCP Client, que usa las herramientas de cualquier servidor MCP como un paso normal del flujo. El punto de acceso MCP de EveryInfra es https://api.everyinfra.com/mcp; listar las herramientas no pide clave, y a las 10:39 (hora de Singapur) listó 25. Llamamos una vez a everyinfra_call_api con los mismos parámetros que una de las llamadas REST:

{
  "type": "@n8n/n8n-nodes-langchain.mcpClient",
  "typeVersion": 1.1,
  "parameters": {
    "endpointUrl": "https://api.everyinfra.com/mcp",
    "authentication": "bearerAuth",
    "tool": { "__rl": true, "mode": "id", "value": "everyinfra_call_api" },
    "inputMode": "json",
    "jsonInput": "{\"platform\":\"weibo\",\"action\":\"trending\",\"params\":{}}",
    "options": { "timeout": 90000 }
  },
  "credentials": { "httpBearerAuth": { "id": "eiBearer000001", "name": "EveryInfra API Key" } }
}

Lo ejecutamos a las 10:39:52 con n8n execute --id=eiMcpCheck0001. El nodo tardó 9,3 segundos y content[0].text volvió como un objeto con los campos id, platform, action, results, count, billing, quota y async_hint. El conteo fue 10, el cobro 0,000556 USD y la llamada aparece en el registro del servidor (req_0e075488e27f44e6, 10:40:01). Cada resultado traía rank, title, hot_value, is_hot, is_new, label, url y platform, los mismos campos que la respuesta REST a esa misma hora. El transporte fue Streamable HTTP, el que usa el nodo por defecto y uno de los dos transportes estándar de la especificación MCP del 2025-11-25.

¿Por qué no usar MCP para el informe? Por dos motivos. El nodo HTTP Request puede enviar la cabecera Idempotency-Key y el nodo MCP Client no tiene dónde ponerla entre los argumentos de la herramienta, así que una recuperación quedaría sin la protección de «un cobro por día». Además, MCP brilla cuando un modelo elige la herramienta y arma los argumentos, y un informe con 5 llamadas fijas no lo necesita. El MCP Client encaja después de un nodo AI Agent, donde un modelo lee el informe y decide si vale la pena profundizar en un tema; para eso n8n tiene aparte el nodo MCP Client Tool. La línea de comandos tiene otra trampa: con el servicio de n8n en marcha, n8n execute levanta su propio intermediario de tareas en el mismo puerto; le dimos N8N_RUNNERS_BROKER_PORT=5692 solo a ese comando y funcionó. Para configurar el MCP de EveryInfra en Claude, Cursor y otros clientes, mira la guía de MCP remoto y la página del servidor MCP.

Cuánto cambiaron las listas en 45 minutos

¿Basta con un informe al día? Depende de lo rápido que cambie cada lista. Solo medimos 45 minutos, de 10:39 a 11:24 hora de Singapur, así que esto responde a «dentro de una hora», no a «dentro de un día». nuestro script de análisis analysis.py calcula todas las cifras a partir de los 14 registros de ejecución.

Lista por lista, las cifras son estas. En Weibo contamos por rank y dejamos fuera los puestos promocionados (de 0 a 2 de las primeras 10 posiciones en cada ejecución; al contar por posición parecían temas nuevos): entre dos ejecuciones seguidas se mantenían de 7 a 10 temas del top 10, es decir, cada 3 minutos cambiaban de 0 a 3, y en 9 de los 13 pares cambió uno o ninguno; el número 1 cambió dos veces, a las 10:57 y a las 11:18 (hora de Singapur), y solo 4 temas estaban a la vez en el primer y en el último top 10. En Douyin, el número 1 fijado no cambió nunca; entre dos ejecuciones seguían de 7 a 10 temas y 5 coincidían entre la primera y la última (la primera solo trajo 8 filas).

Las dos listas de X no cambiaron nada en las primeras 8 ejecuciones. En la de las 11:12 cambiaron a la vez: en la de EE. UU., «Chiefs» subió al número 1, y en la de México entró en el puesto 2 una etiqueta de un programa de televisión, de modo que solo 6 temas siguieron respecto a la ejecución anterior. Después, las dos volvieron a quedarse quietas. Entre la primera y la última ejecución, la lista de EE. UU. conservó 9 temas y la de México, 6.

El efecto de los puestos promocionados en las cifras de Weibo, lado a lado:

Visto desde otro ángulo: en 45 minutos, 21 temas distintos con puesto llegaron al top 10 de Weibo (27 contando por posición; los 6 de más son puestos promocionados que rotan), 18 al de Douyin, 14 al de X México y 11 al de X EE. UU. Un informe que corre una vez al día muestra 10 por lista. Para X eso cubre casi toda la hora; para Weibo, más de la mitad de los temas que pasaron por el top 10 en esa hora nunca aparecerían en tu informe.

Estas cifras muestran que las cuatro listas van a ritmos distintos, no que una sea mejor que otra. Las listas de X eran frescas en cada llamada: collected_at caía unos segundos antes de cada llamada, por ejemplo 10:39:34 y 10:42:35 hora de Singapur. Lo que pasa es que el top 10 se quedó igual casi todo el tiempo y luego cambió de golpe, mientras la elección de Brasil de la noche anterior ocupaba los primeros puestos. Solo vimos un cambio de ese tipo, así que no podemos decir cada cuánto renueva X sus listas. La página de recomendaciones de tendencias de X explica que las tendencias son temas «popular now», que X filtra cuentas nuevas y con pocos seguidores y que detecta tendencias por país, región y ciudad. Por eso X se mueve más despacio que la lista caliente de Weibo, que se actualiza cada minuto. Para tu informe: si te interesan las grandes noticias en X México, una o dos ejecuciones al día bastan. Si quieres seguir los vaivenes de Weibo, una al día se pierde muchos temas que suben y bajan entre ejecuciones; ejecútalo más seguido o guarda todas las listas y reporta «todos los temas vistos hoy».

¿La clave llegó al disco?

Un informe corre durante mucho tiempo, y una clave que acaba en una exportación, en los datos de ejecución o en una copia de seguridad se queda ahí igual de tiempo. Al terminar la prueba, a las 11:25 (hora de Singapur), detuvimos n8n y buscamos el texto de la clave en tres lugares: toda la carpeta de datos de n8n (la base SQLite con su archivo WAL, el registro de eventos y la configuración), los 16 informes de reports/ y todos los archivos crudos de este artículo. Hubo 0 coincidencias. La tabla de credenciales guarda solo el valor cifrado; en los datos de ejecución, la salida del nodo HTTP Request incluye el estado, las cabeceras de respuesta y el cuerpo, pero no las cabeceras de la petición, y los datos de error de las llamadas 422 tampoco traían la clave.

Revisamos los datos de error a propósito. El 14 de octubre, n8n corrigió un problema relacionado: el aviso GHSA-qmvv-q3c9-wpp7 explica que los nodos Git, MongoDB Atlas Vector Store y Google Cloud Storage guardaban en los datos de error una contraseña o un token de su credencial cuando una operación fallaba, de modo que alguien que pudiera ver las ejecuciones, pero no la credencial, podía leer el secreto. Las versiones corregidas son 1.123.85, 2.44.1 y 2.43.5. El nodo HTTP Request no está en la lista y nuestra prueba no encontró fugas, pero muestra por qué conviene buscar secretos en los datos de ejecución después de cada actualización.

Problemas que nos encontramos de verdad

Cada fila de abajo ocurrió durante esta prueba, en orden. Casi ninguna es un error de n8n: salen de los nuevos valores por defecto de la 2.x combinados con el uso por línea de comandos.

La primera fila fue la que más tiempo nos costó y es fácil de malinterpretar: el error nombra un paquete de registros que no tiene nada que ver con n8n y parece un problema de Node.js, cuando en realidad la instalación no terminó. Las filas tres y cuatro van juntas. En el editor, escribir en la base y activar el flujo ocurren en el mismo clic, así que la fase es el segundo en que haces clic; con la línea de comandos y un reinicio, la fase es el segundo en que el reinicio activa el flujo, y en nuestra prueba hubo 3 minutos y 25 segundos entre una cosa y otra. Si despliegas informes por línea de comandos y necesitas que «cada N minutos» coincida con otro sistema, recuerda que la fase se fija al reiniciar.

Los avisos de obsolescencia merecen una lectura con calma. El registro de arranque de las 10:36 enumeró seis: N8N_UNVERIFIED_PACKAGES_ENABLED pasará a false por defecto; el modo interno del ejecutor de tareas desaparecerá y habrá que pasar al modo externo; el tiempo límite N8N_RUNNERS_TASK_TIMEOUT bajará de 300 a 60 segundos; bajarán dos límites del nodo de compresión, y «Running n8n outside a container is deprecated». El tiempo límite de tareas importa para los informes: después de la 3.0, una tarea de un nodo Code que pase de 60 segundos se detendrá, así que fíjalo tú o divide el trabajo. La página del ejecutor de tareas explica el modo externo.

Cómo comprobarlo tú mismo en SQLite

El editor de n8n lista las ejecuciones, pero no muestra «la ejecución que debía ocurrir y no ocurrió». El planificador durable guarda eso en dos tablas que sqlite3 puede leer. Estas son las tres consultas que usamos para decidir J1 a J4:

DB=$HOME/Downloads/n8n-lf25/home/.n8n/database.sqlite
# 1. Fase, intervalo, política y gracia de cada programación
sqlite3 -header $DB "select name, intervalSeconds, nextRunAt, lastFiredAt, misfirePolicy, misfireGraceSeconds from scheduled_job;"
# 2. Cada ejecución en la cola: hora prevista, inicio real e inicio más tardío permitido
sqlite3 -header $DB "select id, jobId, status, scheduledFor, startedAt, missedAfter from scheduled_task order by id;"
# 3. Ejecuciones que ocurrieron: modo, estado e inicio (todo en UTC)
sqlite3 -header $DB "select id, workflowId, mode, status, startedAt from execution_entity order by id;"

Ten en cuenta tres cosas. Las horas están en UTC: suma 8 para la hora de Singapur o resta 6 para la Ciudad de México. La tabla scheduled_task solo guarda ejecuciones que entraron en la cola, y la ventana es de 60 segundos por defecto; una ejecución que tocó durante la parada y ya había superado su gracia al volver n8n nunca aparece ahí. Por eso las ejecuciones perdidas no se cuentan contando filas: se deducen de la fase o se leen en n8n_scheduler_occurrences_misfired_total. Así lo hicimos: las ejecuciones de A de las 10:51:24 y las 10:54:24 no tienen fila; las dedujimos de «fase + 180 s × k» y las cuadramos con el valor 2 del contador. Por último, las ejecuciones terminadas se guardan un día por defecto (N8N_SCHEDULER_RETENTION vale 86.400 segundos) y las fallidas o perdidas, siete días; para una revisión mensual hay que exportarlas periódicamente. Exportamos las tres tablas a executions.json, y nuestro script de análisis analysis.py calcula a partir de ese archivo todas las horas de este artículo.

Esta tabla relaciona cada criterio con la evidencia que lo decidió. Conservamos todos los archivos archivados.

Referencia de campos

El informe usa solo el nombre y la posición de cada fila, pero las 4 capacidades devuelven más. Cotejamos esta tabla campo por campo con los response_fields del catálogo, leído a las 10:15 hora de Singapur. La columna «En esta ejecución» muestra qué campos traían las filas de la ejecución de las 10:39.

Tres avisos que solo encontramos al revisar fila por fila las respuestas crudas. La fila fijada de Douyin (is_pinned: true) no trae hot_value, pero las otras 19 sí; si ordenas por calor, la fijada queda al final, así que ordena Douyin por rank. Un mismo campo, event_time, llegó en dos formatos: la fila fijada usaba «2026-10-26 10:41:56», sin zona horaria, y las demás «2026-10-25T01:23:31.000Z», en UTC; compararlas como texto da resultados erróneos, así que interpreta los dos formatos. Y Weibo no devolvió category en ninguna de las 14 ejecuciones: no supongas que un campo siempre está, léelo con un valor por defecto, por ejemplo x.category ?? '', o el nodo Code lanzará un error el día que falte. Otros valores de boards pueden comportarse distinto; no los probamos. Los parámetros y campos completos están en la página de la API de tendencias de X, la de Weibo y la de Douyin; la vista general de cada plataforma, en la API de X, la API de Weibo y la API de Douyin.

La misma llamada desde código

Si todavía no quieres instalar n8n, este comando curl envía la misma petición que el nodo HTTP Request del paso 4. Úsalo para comprobar la clave y los parámetros en una terminal.

curl -s https://api.everyinfra.com/api/v1/social \
  -H "Authorization: Bearer ${EVERYINFRA_API_KEY}" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: daily-report-$(TZ=America/Mexico_City date +%Y%m%d)-twitter-mx" \
  -d '{"platform":"twitter","action":"trending","params":{"country":"mx"}}' \
  | jq '{replayed, count, top3: [.results[0:3][].name], charged_usd: .billing.charged_usd}'

Si lo ejecutas otra vez el mismo día, replayed pasa a true; charged_usd sigue mostrando el primer valor, pero no hay cobro nuevo. Fíjate en que la fecha de la clave usa la hora de la Ciudad de México: elige una zona horaria para la clave y usa la misma en n8n, porque si no, un informe cerca de la medianoche puede estrenar clave antes o después de lo que esperas. Para conseguir una clave y ver el formato de petición y respuesta, empieza por el inicio rápido; los precios de cada capacidad están en la página de precios. Si tu informe también revisa los reembolsos de llamadas fallidas, la guía de conciliación de reembolsos explica cómo cuadrar cada cobro con charge_id y el registro de llamadas.

Otras formas de hacer lo mismo

No hace falta n8n para un informe diario. Esta tabla solo recoge hechos que pudimos comprobar y cuándo conviene cada opción.

«cron no recupera» describe el cron clásico; algunos temporizadores sí recuperan, como un temporizador de systemd con Persistent=true, y no los probamos. Nuestra regla: para una o dos llamadas sin rama de fallos, cron y curl son más ligeros; para tres pasos o más, fallos que deben quedar en el informe o un flujo que otras personas editan, n8n. Nuestra guía de monitoreo de reputación en varias plataformas usa otro enfoque, por si quieres comparar.

Cuándo esta configuración no es la adecuada

Necesitas cada ejecución, exactamente una vez. La política de recuperación ejecuta como máximo la más reciente perdida, no todas; la documentación dice que ninguna política repite el atraso ejecución por ejecución. Si necesitas cada copia horaria, por ejemplo para calcular un promedio diario, revisa en el informe las horas previstas y rellena tú los huecos.

Compartes una base SQLite entre varias instancias de n8n. Solo probamos una instancia. La documentación dice que con varias instancias principales cada ejecución la reclama una sola, pero eso requiere Postgres y el modo de colas, que no probamos.

Necesitas la lista completa. Por defecto cada llamada trae 20 filas, y la primera trajo solo 10 y 8 (ver prueba 3).

Necesitas una ventana larga. Medimos 45 minutos de la noche del 25 de octubre en México (mañana del 26 en Singapur), justo después de la elección de Brasil, cuando una sola noticia dominaba todas las listas.

Cambios recientes

• 20 de octubre de 2026: n8n 2.45 enciende por defecto el planificador durable. Ver el registro de cambios y las notas de la versión en GitHub, que además eliminan N8N_SCHEDULER_MIN_INTERVAL, que ya no se usaba. Para ti: tras actualizar, «cada N minutos» tiene otra fase y las paradas se comportan distinto; revisa la política de cada flujo programado.
• Desde la 3.0: solo Docker. La página de cambios incompatibles de la 3.0 termina el soporte de npm y npx n8n y elimina los nodos antiguos Cron e Interval. Para ti: la instalación con npm de este artículo es para probar; pasa los informes de larga duración a Docker y cambia los nodos Cron por Schedule Trigger.
• 14 de octubre de 2026: actualización de seguridad de n8n. La actualización trae 15 avisos, entre ellos credenciales dentro de los datos de error. Para ti: mantén tu instancia en el último parche y busca secretos en los datos de ejecución después de actualizar.
• 14 de octubre de 2026: Censys señala a n8n como el producto de IA más expuesto. El informe de Censys cuenta 113.926 instalaciones. Para ti: un n8n que solo arma tu informe no tiene por qué estar abierto a internet.
• 6 de octubre de 2026: Diagrid anuncia ejecución durable para n8n. Un comunicado de prensa pagado dice que los flujos siguen desde el nodo que falló tras una caída, con un registro de idempotencia contra efectos repetidos. Para ti: la 2.45 garantiza que una ejecución prevista no se pierda; una caída a mitad de ejecución es otro problema, y otras empresas ya trabajan en él.
• 12 de octubre de 2026: ZoomInfo lanza un nodo nativo para n8n. El comunicado en Business Wire dice que también ofrece sus datos por API y MCP. Para ti: los servicios de datos llegan a n8n por nodos propios y por MCP. EveryInfra no tiene hoy un nodo propio de n8n; este artículo usa los nodos generales HTTP Request y MCP Client.
• 22 de octubre de 2026: el borrador de la IETF sobre Idempotency-Key llega a la versión 08. Ver la página del datatracker de la IETF. Para ti: la idempotencia mediante una cabecera se está volviendo estándar, así que una clave por fecha te sirve también con otras API.

Preguntas frecuentes

¿Cómo cambio la zona horaria de n8n? (Fuente: sugerencia de Google «n8n zona horaria», leída el 26 oct 2026)

Una instancia propia de n8n usa America/New_York por defecto. Pon GENERIC_TIMEZONE=America/Mexico_City (o la zona de tu ciudad) y reinicia; también puedes fijar la zona en los ajustes de cada flujo, que mandan sobre la de la instancia (página del Schedule Trigger). Si estás en la frontera norte, usa el nombre de la IANA de tu ciudad, porque ahí sí cambia la hora.

¿Por qué mi Schedule Trigger de n8n no corrió después de reiniciar? (Fuente: sugerencia de Google «n8n schedule trigger not running», leída el 26 oct 2026)

Mira primero la versión. Hasta la 2.44, el planificador en memoria salta todo lo que toque durante la parada. Desde la 2.45, el planificador durable lo ejecuta tarde si n8n vuelve dentro de la gracia (60 segundos por defecto); después, decide el ajuste del nodo «If Execution Is Missed», que por defecto también descarta. En nuestra parada de 6 minutos y 44 segundos, la política por defecto descartó dos ejecuciones, tal como está diseñado. Para recuperar, elige «Run the Most Recent Missed Execution» y usa una clave por fecha para que la recuperación no se cobre dos veces.

¿Cómo manejo los errores de HTTP Request en n8n sin detener el flujo? (Fuente: sugerencia de Google «n8n http request error handling», leída el 26 oct 2026)

Activa «Never Error» e «Include Response Headers and Status» en las opciones del nodo HTTP Request. Así una respuesta que no es 2xx pasa al siguiente nodo como datos y puedes ramificar según statusCode. En nuestras 14 ejecuciones, la llamada mal escrita devolvió 422 todas las veces y el informe llegó todas las veces. Los errores de EveryInfra traen next_steps, que puedes copiar tal cual en el informe.

Lecturas relacionadas

• MCP remoto: conectar el MCP de EveryInfra en Claude, Cursor y otros clientes.
• Conciliación de reembolsos: cuadrar cada cobro y cada reembolso.
• Vender informes de temas a partir de comentarios de YouTube: otro informe programado, mensual.
• La especificación MCP 2026 y su uso en producción: contexto sobre transportes y autenticación en MCP.

Referencias

1. Durable scheduler, n8n Docs, oct 2026, <https://docs.n8n.io/deploy/host-n8n/configure-n8n/durable-scheduler/>
2. Variables de entorno del planificador, n8n Docs, oct 2026, <https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/scheduler/>
3. Nodo Schedule Trigger, n8n Docs, oct 2026, <https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.scheduletrigger/>
4. Changelog (planificador durable por defecto), n8n Docs, 2026-10-20, <https://docs.n8n.io/changelog/>
5. Release notes (n8n 2.45 y 2.44), n8n Docs, 2026-10-20, <https://docs.n8n.io/changelog/release-notes/>
6. Release n8n 2.45.0, n8n en GitHub, 2026-10-20, <https://github.com/n8n-io/n8n/releases/tag/n8n%402.45.0>
7. v3.0 Breaking changes, n8n Docs, oct 2026, <https://docs.n8n.io/changelog/v30-breaking-changes/>
8. Developing v3 features, n8n en GitHub, 2026, <https://github.com/n8n-io/n8n/blob/master/.github/DEVELOPING_V3.md>
9. Install with npm, n8n Docs, oct 2026, <https://docs.n8n.io/deploy/host-n8n/install-options/install-with-npm/>
10. Metadatos del paquete n8n (dist-tags y fechas), registro de npm, leído el 26 oct 2026, <https://registry.npmjs.org/n8n>
11. Use Docker Compose, n8n Docs, oct 2026, <https://docs.n8n.io/deploy/host-n8n/install-options/install-using-docker-compose/>
12. One-line setup, n8n Docs, oct 2026, <https://docs.n8n.io/deploy/host-n8n/install-options/one-line-setup/>
13. Node.js Releases, Node.js, actualizado el 21 oct 2026, <https://nodejs.org/en/about/previous-releases>
14. Set the timezone, n8n Docs, <https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/configuration-examples/set-the-timezone/>
15. Ley de los Husos Horarios en los Estados Unidos Mexicanos, Cámara de Diputados (DOF 28-10-2022, última reforma 29-11-2022), <https://www.diputados.gob.mx/LeyesBiblio/pdf/LHHEUM.pdf>
16. Daylight Saving Time Rules, NIST, 2026, <https://www.nist.gov/pml/time-and-frequency-division/popular-links/daylight-saving-time-dst>
17. Time Zone Database, IANA, <https://www.iana.org/time-zones>
18. Variables de entorno de seguridad, n8n Docs, <https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/security/>
19. Nodo Read/Write Files from Disk, n8n Docs, <https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.readwritefile/>
20. Use the command line, n8n Docs, <https://docs.n8n.io/deploy/host-n8n/configure-n8n/use-the-command-line/>
21. Credenciales de HTTP Request, n8n Docs, <https://docs.n8n.io/integrations/builtin/credentials/httprequest/>
22. RFC 6750: Bearer Token Usage, IETF, 2012, <https://www.rfc-editor.org/rfc/rfc6750>
23. OpenAPI de EveryInfra (claves de idempotencia, repeticiones, errores), EveryInfra, leído el 26 oct 2026, <https://api.everyinfra.com/openapi.json>
24. The Idempotency-Key HTTP Header Field, borrador 08, grupo HTTPAPI de la IETF, 2026-10-22, <https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/>
25. Nodo HTTP Request, n8n Docs, <https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest/>
26. getWorkflowStaticData, n8n Docs, <https://docs.n8n.io/build/code-in-n8n/cookbook/built-in-methods-and-variables-examples/getworkflowstaticdata/>
27. Nodo Convert to File, n8n Docs, <https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.converttofile/>
28. Enable Prometheus metrics, n8n Docs, <https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/configuration-examples/enable-prometheus-metrics/>
29. Panel de Grafana n8n-scheduler, n8n-observability en GitHub, <https://github.com/n8n-io/n8n-observability/tree/main/dashboards/grafana/n8n-scheduler>
30. Catálogo de capacidades de EveryInfra, EveryInfra, leído el 26 oct 2026 a las 10:15 hora de Singapur, <https://api.everyinfra.com/api/v1/social/catalog>
31. Reglas de la lista caliente, Weibo, <https://m.s.weibo.com/hot/description>
32. RFC 9110: HTTP Semantics (422 Unprocessable Content), IETF, 2022, <https://www.rfc-editor.org/rfc/rfc9110>
33. Handle errors gracefully, n8n Docs, <https://docs.n8n.io/build/flow-logic/handle-errors-gracefully/>
34. Nodo MCP Client, n8n Docs, <https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-langchain.mcpclient/>
35. Nodo MCP Client Tool, n8n Docs, <https://docs.n8n.io/integrations/builtin/cluster-nodes/sub-nodes/n8n-nodes-langchain.toolmcp>
36. Especificación MCP 2025-11-25: Transports, Model Context Protocol, <https://modelcontextprotocol.io/specification/2025-11-25/basic/transports>
37. Trends Recommendations, Centro de ayuda de X, <https://help.x.com/en/resources/recommender-systems/trends-recommendations>
38. Set up task runners, n8n Docs, <https://docs.n8n.io/deploy/host-n8n/configure-n8n/set-up-task-runners/>
39. GHSA-qmvv-q3c9-wpp7: Credential Secrets Exposed in Execution Error Data, n8n en GitHub, 2026-10-14, <https://github.com/n8n-io/n8n/security/advisories/GHSA-qmvv-q3c9-wpp7>
40. 5 Key Takeaways From Censys' State of the Internet Report, Censys, 2026-10-14, <https://censys.com/blog/state-of-the-internet-report-2026/>
41. Security update — 01 October 2026, comunidad de n8n, 2026-10-01, <https://community.n8n.io/t/security-update-01-october-2026/318054>
42. Security update — 14 October 2026, comunidad de n8n, 2026-10-14, <https://community.n8n.io/t/security-update-14-october-2026/321284>
43. Diagrid Brings Durable Execution to n8n (comunicado pagado), Business Wire vía Yahoo Finance, 2026-10-06, <https://finance.yahoo.com/technology/ai/articles/diagrid-brings-durable-execution-n8n-130000140.html>
44. ZoomInfo Launches Native Integration With n8n Through GTM.AI, Business Wire, 2026-10-12, <https://www.businesswire.com/news/home/20261012317239/en/ZoomInfo-Launches-Native-Integration-With-n8n-Through-GTM.AI>
45. Faltam 12 dias: consulte propostas das candidaturas que disputam o 2º turno, Tribunal Superior Electoral de Brasil, 2026-10-13, <https://www.tse.jus.br/comunicacao/noticias/2026/Outubro/faltam-12-dias-consulte-propostas-das-candidaturas-que-disputam-o-2o-turno>
46. An n8n execution can show Success after processing zero items, Reddit r/n8n, <https://www.reddit.com/r/n8n/comments/1xadlkd/an_n8n_execution_can_show_success_after/>