Google Sheets Trigger devuelve errores intermitentes 503 Service Unavailable en múltiples flujos de trabajo durante más de 24 horas

Preguntas
, , ,
1

Describe el problema/error/pregunta

Mi nodo Disparador de Google Sheets (sondeo cada minuto, evento rowAdded) está fallando intermitentemente con un error 503 en dos flujos de trabajo separados que monitorean dos Google Sheets diferentes bajo dos credenciales OAuth2 diferentes. Esto ha ocurrido repetidamente desde el 12 de julio 06:56 hasta el 13 de julio 23:03.
Ya he verificado las causas estándar antes de publicar:
Ambas credenciales OAuth2 de Google Sheets muestran “Cuenta conectada” sin necesidad de reautenticación.
La página de estado de n8n muestra un incidente (20 minutos el 13 de julio, de 10:58 a 11:18 en hora local), pero no se superpone con ninguna de mis marcas de tiempo de error.
El panel de estado de Google Workspace muestra que Sheets está en buen estado durante todo el período.
Retry On Fail ya estaba habilitado en uno de los dos flujos de trabajo afectados antes de que estos errores comenzaran, y los errores persistieron de todas formas, por lo que esto no parece ser un problema transitorio normal que los reintentos puedan absorber.
Encontré dos hilos pasados similares (vinculados a continuación) donde la solución sugerida fue habilitar Retry On Fail, pero como ya estaba activado para uno de mis flujos de trabajo y no ayudó, quería señalar esto como un problema posiblemente diferente o más persistente.
Hilos relacionados que encontré:

Google Sheets Trigger executions - Could not complete

¿Cuál es el mensaje de error (si lo hay)?

{
“errorMessage”: “Servicio no disponible - intenta de nuevo más tarde o considera configurar este nodo para reintentar automáticamente (en la configuración del nodo)”,
“errorDescription”: “El servicio no está disponible en este momento.”,
“errorDetails”: {},
“n8nDetails”: {
“n8nVersion”: “2.29.8 (Cloud)”,
“binaryDataMode”: “filesystem”
}
}

Por favor comparte tu flujo de trabajo

(Selecciona los nodos en tu lienzo y usa los atajos de teclado CMD+C/CTRL+C y

image
image333×232 8.6 KB

CMD+V/CTRL+V para copiar y pegar el flujo de trabajo.)

Comparte el resultado devuelto por el último nodo

No aplica. El nodo disparador en sí falla antes de devolver ningún resultado, por lo que ningún nodo descendente se ejecuta.

Información sobre tu configuración de n8n

    1. Versión de n8n: 2.29.8
    2. Base de datos (predeterminada: SQLite): Gestionada en la nube de n8n
    3. Configuración n8n EXECUTIONS_PROCESS (predeterminada: own, main): predeterminada (Gestionada en la nube)
    4. Ejecutando n8n mediante (Docker, npm, n8n cloud, aplicación de escritorio): n8n Cloud
    5. Sistema operativo: n8n Cloud
2

@Kalon

Sondear cada minuto consume muchos recursos y es propenso a estos errores. La forma más robusta de manejar eventos de „Fila agregada

3

¡Bienvenido @Kalon!

El 503 aquí proviene de la API de Google, no de n8n. El disparador de sondeo de Sheets llama a la API de Sheets en cada intervalo y Google a veces rechaza solicitudes en el perímetro del servicio incluso cuando la página de estado pública se ve verde. Dos cosas que verificar: primero, mira el cuerpo del error sin procesar en el registro de ejecución — si incluye backendError o serviceUnavailable en el JSON, eso confirma que el backend de Google es el culpable. Segundo, intenta cambiar el intervalo de sondeo a cada 5 minutos en lugar de cada 1 minuto — el sondeo agresivo con múltiples credenciales golpeando la misma cuota de API de Sheets puede agravar esto. Si necesitas detección casi en tiempo real, cambiar a un enfoque basado en webhooks a través de Google Apps Script (dispara tu webhook de n8n al cambiar la hoja) es mucho más confiable que el sondeo y evita completamente esta clase de error.

4

Hola @Kalon
Si ambas credenciales son del tipo OAuth2 gestionado «Sign in with Google», se ejecutan a través del cliente de Google compartido de n8n en Cloud, por lo que dos cuentas diferentes fallan en la misma ventana y por eso no tienes ningún panel de API para consultar. Recrea la credencial como OAuth2 personalizado usando un cliente de tu propio proyecto de Google Cloud y apunta ambos flujos de trabajo a él. Luego abre APIs and Services > Google Sheets API > Metrics en ese proyecto: el desglose del código de respuesta muestra la razón que Google adjunta a cada 503, y tus sondeos se ejecutan contra tu propio cliente en lugar de uno compartido.

5

El 503 viene del lado de Google, no de n8n — y en n8n Cloud, el Sheets Trigger utiliza el cliente OAuth compartido de Google de n8n, por lo que estás compartiendo la cuota de API de ese cliente con todos los demás usuarios de Cloud. Cuando Google limita ese proyecto compartido, obtienes 503s intermitentes aunque tus propias credenciales y volumen estén bien. Por eso afecta ambos flujos de trabajo con credenciales diferentes al mismo tiempo, y por eso Retry On Fail no lo resuelve — un trigger de sondeo no vuelve a escanear las filas que omitió durante los ciclos fallidos, así que el riesgo real aquí es perder filas silenciosamente, no la línea de error en sí.

Dos soluciones, en orden de impacto:

  1. Cambiar a OAuth2 personalizado — crea tu propio proyecto de Google Cloud + cliente OAuth y úsalo como credencial. Te sacas de la cuota compartida a la tuya propia, lo que generalmente elimina los 503s intermitentes completamente.

  2. Reemplaza el sondeo con un push — un trigger onChange de Google Apps Script que envíe POST de filas nuevas a un Webhook de n8n. Sin sondeo significa sin ventana de filas perdidas (envuelve el lado de Apps Script en try/catch, ya que tiene sus propias cuotas).

De cualquier forma, añade una pequeña red de seguridad: un flujo de trabajo programado cada 15–30 min que relea la última hora de filas y elimine duplicados basándose en el id de fila o una columna de marca de tiempo — así cualquier cosa descartada durante una ventana de 503 se recopilará de todas formas.

6

La explicación de shared-OAuth-client anterior es muy probablemente correcta, y pasar a un cliente personalizado es el siguiente paso correcto. Pero todos aquí (yo incluido, hasta que releí tu mensaje) estamos discutiendo sobre cuál encuesta corregir, y creo que la pregunta más útil es por qué estás sondeando en primer lugar.

rowAdded en un intervalo de 60 segundos es n8n preguntándole a Google «¿ha cambiado algo?» 1.440 veces al día, por flujo de trabajo, para siempre — y la abrumadora mayoría de esas llamadas no devuelven nada. Cada una de ellas es una oportunidad de recibir un 503, y pasar a tu propio cliente OAuth reduce esa exposición sin eliminarla, porque 503 es lo que devuelve el backend de Google bajo carga independientemente de quién sea tu cliente.

Push en lugar de poll. En la hoja: Extensions → Apps Script, luego algo como:


function onRowAdded(e) {
  UrlFetchApp.fetch('https://
<tu-n8n>
/webhook/
<ruta>
', {
    method: 'post',
    contentType: 'application/json',
    payload: JSON.stringify({ range: e.range.getA1Notation(), values: e.range.getValues() })
  });
}
```

...vinculado como un activador instalable (Triggers → Add Trigger → On change, u On form submit si las filas llegan desde un Formulario). En n8n, reemplaza el Sheets Trigger por un nodo Webhook.

Lo que eso te proporciona: **cero llamadas a la API de Sheets**, por lo que toda la clase de fallo que estás persiguiendo desaparece en lugar de volverse más rara. Apps Script se ejecuta *dentro* de Sheets y no toca la API REST de Sheets ni su cuota, por lo que un 503 de Google API no puede perder tu evento. También es instantáneo en lugar de llegar con hasta 60 segundos de retraso, y no cuesta nada.

Dos advertencias honestas, porque esto no es gratis:

- `onChange` no se activa para ediciones realizadas por *otras* escrituras de API o scripts. Si algunas filas llegan a través de la API de Sheets en lugar de un humano o un Formulario, no las activarán — comprueba cómo llegan realmente las filas antes de comprometerte.
- Ahora dependes de que tu webhook sea accesible. Apps Script no volverá a intentarlo de manera significativa, por lo que un reinicio de n8n durante un POST pierde ese evento.

Por eso el barrido de red de seguridad sugerido anterior sigue siendo válido independientemente del activador que uses: un flujo de trabajo programado que relée las últimas N filas y elimina duplicados en una identificación de fila. Push para la latencia, barrido para la corrección. Esa combinación es lo que ejecutaría en producción, y es lo que te permite responder realmente la pregunta «¿perdí silenciosamente una fila durante una ventana de 503?» en lugar de asumir.

Una última cosa que vale la pena verificar antes de avanzar: durante esas ventanas de fallo, ¿se perdieron realmente *filas*, o la siguiente encuesta exitosa las recogió? Los 503 son ruidosos e irritantes, pero la pérdida silenciosa de datos es lo que realmente te lastimará, y vale la pena confirmar cuál fue el que tuviste.
7

@Kalon
El error 503 Service Unavailable en n8n (Google Sheets Trigger) indica un problema temporal en el lado del servidor de destino—en este caso, la Google Sheets API es temporalmente incapaz de procesar la solicitud.

Las causas y soluciones se pueden desglosar de la siguiente manera:

¿Qué lo causa?

  1. Sobrecarga del servidor de Google o tiempo de inactividad temporal (Error transitorio): Esta es la causa más común. Los servidores de Google podrían estar reiniciándose, realizando mantenimiento o manejando un volumen de tráfico inusualmente alto en ese momento específico.

  2. Polling demasiado frecuente: El flujo de trabajo verifica actualizaciones cada 1 minuto. Ejecutar un disparador de sondeo con esta frecuencia tan alta puede causar que la API de Google vea las solicitudes como demasiado agresivas, bloqueando temporalmente la conexión para evitar sobrecargas (incluso si no devuelve explícitamente un error 429 Too Many Requests).

  3. Problemas de red intermitentes: Podría haber una breve pérdida de conectividad o un tiempo de espera de protocolo de enlace entre tu instancia de n8n y los servidores de Google.

¿Cómo arreglarlo?

1. Habilitar “Retry On Fail” (Como recomienda el sistema) Esta es la forma más efectiva de manejar estos tipos de errores transitorios.

  • Ve a la Node Settings (icono de engranaje) del Google Sheets Trigger.

  • Activa Retry On Fail.

  • Configura el número de reintentos (por ejemplo, 3 veces) y el tiempo de espera entre intentos. Esto evita que el flujo de trabajo se bloquee inmediatamente al encontrar un error 503 temporal.

2. Aumentar el intervalo de sondeo Si tu disparador verifica datos demasiado frecuentemente (como cada minuto), considera extender el intervalo para reducir la carga general de la API.

  • Cambia el intervalo para verificar cada 5 minutos o 15 minutos si las actualizaciones en tiempo real no son estrictamente necesarias para tu caso de uso.

3. Verificar las cuotas de Google Cloud Console Si estás utilizando tus propias credenciales OAuth2 personalizadas (en lugar de las credenciales de nube predeterminadas de n8n):

  • Inicia sesión en Google Cloud Console y verifica la sección de Cuotas para la Google Sheets API para asegurarte de que no estés alcanzando limitaciones por minuto o por día.

4. Verificar el estado del servicio de Google A veces Google Workspace experimenta interrupciones. Puedes monitorear la salud en tiempo real de sus servicios en el Google Workspace Status Dashboard. Si Google está experimentando una interrupción generalizada, simplemente tendrás que esperar hasta que su equipo resuelva el problema.

8

Creo que aquí hay un par de cosas que se están mezclando.

Un 503 suele ser un error transitorio del lado de Google, pero no lo agruparía automáticamente con problemas de cuota o sondeo agresivo. Si Google cree que estás excediendo cuotas, normalmente ves respuestas 429 o 403 relacionadas con cuota, no 503.

Además, no estoy convencido de que habilitar Retry On Fail sea necesariamente la respuesta aquí si el fallo está ocurriendo en el nivel de sondeo del disparador en sí. Los nodos de disparador se comportan de manera diferente a los nodos de flujo de trabajo normales, por lo que sería útil confirmar si los reintentos se aplican realmente a los fallos de sondeo de Google Sheets Trigger o solo a las ejecuciones de nodos posteriores.

La explicación de OAuth compartida parece mucho más plausible, especialmente porque varios usuarios parecen estar viendo esto alrededor de la misma hora. Pasar a un cliente OAuth personalizado te aísla del comportamiento del cliente compartido y es probablemente lo primero que probaría.

Dicho esto, creo que la pregunta más importante es la que Adam planteó anteriormente:

¿Se perdió realmente algo?

¿Se omitieron filas de manera permanente, o el siguiente sondeo exitoso simplemente se puso al día y las procesó normalmente?

Porque hay una gran diferencia entre:

  • errores 503 ruidosos y transitorios en los registros, y
  • pérdida silenciosa de datos.

El primero es molesto.

El segundo es un problema de producción.

Con respecto a la sugerencia de Apps Script, hay un detalle importante que vale la pena mencionar:

e.range y e.values funcionan para ciertos tipos de disparadores como On form submit, pero no se garantiza que existan para un disparador instalable genérico On change. Por lo tanto, la implementación de ejemplo puede funcionar perfectamente para algunos flujos de trabajo y fallar inmediatamente para otros, dependiendo de cómo entren las filas en la hoja.

El enfoque de webhook sigue siendo atractivo porque eliminar el sondeo elimina toda la clase de fallos de sondeo, pero introduce un modo de fallo diferente en su lugar:

si el punto final del webhook no está disponible durante la entrega, Apps Script no te dará reintentos duraderos o encolamiento.

Personalmente ejecutaría:

  • entrega push/webhook para baja latencia,
  • procesamiento idempotente usando un ID de fila,
  • y un flujo de trabajo de reconciliación programada que revise filas recientes periódicamente.

Push por velocidad.

Barrida por corrección.

Esa combinación sobrevive a los problemas de API, el tiempo de inactividad del webhook, los reinicios del flujo de trabajo y prácticamente todos los casos límite desagradables que eventualmente aparecen en producción.

En este punto estaría interesado en tres cosas antes de sacar conclusiones:

  1. ¿OAuth de n8n compartido u OAuth personalizado?
  2. ¿Se omitieron realmente filas?
  3. ¿Todos los usuarios afectados están ejecutándose en la misma región o infraestructura de n8n Cloud?

Esas respuestas probablemente nos dirán si estamos viendo fallos transitorios esperados de Google o un incidente real del lado de n8n que vale la pena investigar más.

9

Hola Kalon,

Un error 503 Service Unavailable típicamente indica que el servidor de la API de Google Sheets está temporalmente sobrecargado o está aplicando límites de velocidad estrictos debido a alta concurrencia.

Ya que estás consultando cada 1 minuto en múltiples flujos de trabajo separados y credenciales OAuth, es muy probable que estés activando las cuotas de solicitudes concurrentes de Google, lo que les hace rechazar las solicitudes de manera intermitente. Como «Retry on Fail» con retrasos cortos predeterminados no lo está capturando, la duración del bloqueo es más larga que los intentos de reintento.

Aquí hay dos formas de resolver este problema de forma permanente:

  1. Consulta Dinámica y Backoff Exponencial (Solución Rápida):
    • Ve a la configuración del nodo de Google Sheets → En «Retry on Fail», aumenta Max Attempts a 5.
    • Aumenta el Retry Delay (Tiempo de Espera) a al menos 5000ms o 10000ms. Esto le da a la API de Google suficiente tiempo de enfriamiento entre reintentos para absorber el bloqueo 503 transitorio.

  2. Cambiar de Consulta a Arquitectura Push mediante Webhooks (Recomendado :rocket:):
    En lugar de que n8n consulte Google Sheets cada minuto, puedes invertir la arquitectura.
    • Reemplaza el Trigger de Google Sheets con un nodo Webhook de n8n.
    • Añade un simple Google Apps Script de 5 líneas (trigger onEdit) a tu Google Sheets que automáticamente dispare una solicitud POST a tu Webhook de n8n siempre que se añada una nueva fila.

Esto completamente evita los límites de velocidad de consulta, elimina los errores 503 por completo y ahorra una cantidad masiva de gastos de ejecución de n8n.

¡Avísame si necesitas ayuda estructurando la configuración de Google Apps Script, puedo compartirte el bloque de script!