Google Sheets Trigger retourne intermittently 503 Service Unavailable sur plusieurs workflows depuis plus de 24 heures

Questions
, , ,
1

Décrivez le problème/l’erreur/la question

Mon nœud Google Sheets Trigger (scrutation toutes les minutes, événement rowAdded) échoue par intermittence avec une erreur 503 sur deux flux de travail distincts surveillant deux feuilles Google Sheets différentes sous deux identifiants OAuth2 différents. Cela s’est produit à plusieurs reprises du 12 juillet 06:56 au 13 juillet 23:03.
J’ai déjà vérifié les causes standards avant de poster :
Les deux identifiants OAuth2 Google Sheets affichent « Compte connecté » sans nécessiter de réauthentification.
La page de statut de n8n affiche un incident (20 minutes le 13 juillet, de 10:58 à 11:18 en heure locale), mais il ne chevauche aucun de mes horodatages d’erreur.
Le tableau de bord de statut de Google Workspace montre Sheets comme sain pour toute la période.
Retry On Fail était déjà activé sur l’un des deux flux de travail affectés avant le début de ces erreurs, et les erreurs ont persisté de toute façon, donc cela ne semble pas être un problème transitoire normal que les tentatives peuvent absorber.
J’ai trouvé deux fils de discussion similaires du passé (liés ci-dessous) où la correction suggérée était d’activer Retry On Fail, mais puisque c’était déjà activé pour l’un de mes flux de travail et que cela n’a pas aidé, je voulais signaler ceci comme un problème possiblement différent ou plus persistant.
Fils connexes que j’ai trouvés :

Quel est le message d’erreur (le cas échéant) ?

{
“errorMessage”: “Service unavailable - try again later or consider setting this node to retry automatically (in the node settings)”,
“errorDescription”: “The service is currently unavailable.”,
“errorDetails”: {},
“n8nDetails”: {
“n8nVersion”: “2.29.8 (Cloud)”,
“binaryDataMode”: “filesystem”
}
}

Veuillez partager votre flux de travail

(Sélectionnez les nœuds sur votre canevas et utilisez les raccourcis clavier CMD+C/CTRL+C et

image
image333×232 8.6 KB

CMD+V/CTRL+V pour copier et coller le flux de travail.)

Partagez la sortie renvoyée par le dernier nœud

Non applicable. Le nœud déclencheur lui-même échoue avant de renvoyer une sortie, donc aucun nœud en aval ne s’exécute.

Informations sur votre configuration n8n

    1. Version de n8n : 2.29.8
    2. Base de données (par défaut : SQLite) : n8n Cloud géré
    3. Paramètre n8n EXECUTIONS_PROCESS (par défaut : own, main) : par défaut (géré par Cloud)
    4. Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) : n8n Cloud
    5. Système d’exploitation : n8n Cloud
2

@Kalon

Le sondage toutes les minutes consomme beaucoup de ressources et est sujet à ces erreurs. La façon la plus robuste de gérer les événements « Ligne ajoutée » est de faire en sorte que Google Sheets envoie les données à n8n instantanément à l’aide d’un simple script Google Apps Script.

  1. Remplacez votre Google Sheets Trigger par un Webhook Node dans n8n.
  2. Copiez l’URL du Webhook de production.
  3. Dans votre feuille Google, allez à Extensions →→ Apps Script et collez un script similaire à celui-ci :
function onFormSubmit(e) {
  var url = "YOUR_N8N_WEBHOOK_URL";
  var options = {
    "method": "post",
    "contentType": "application/json",
    "payload": JSON.stringify(e.values)
  };
  UrlFetchApp.fetch(url, options);
}
  1. Configurez un Installable Trigger dans le tableau de bord Apps Script (l’icône de l’horloge) pour exécuter la fonction onFormSubmit « Lors de la soumission du formulaire » ou « Lors d’une modification ».
3

Bienvenue @Kalon !

Le 503 provient de l’API Google, pas de n8n - le déclencheur de sondage Sheets appelle l’API Sheets à chaque intervalle et Google rejette parfois les demandes à la limite du service même quand la page de statut public semble verte. Deux choses à vérifier : d’abord, regardez le corps d’erreur brut dans le journal d’exécution - s’il inclut backendError ou serviceUnavailable dans le JSON, cela confirme que le backend de Google est le responsable. Deuxièmement, essayez de passer l’intervalle de sondage à toutes les 5 minutes au lieu d’une minute - le sondage agressif avec plusieurs identifiants frappant le même quota d’API Sheets peut aggraver cela. Si vous avez besoin d’une détection en temps quasi réel, le passage à une approche basée sur les webhooks via Google Apps Script (déclenche votre webhook n8n lors d’une modification de feuille) est beaucoup plus fiable que le sondage et évite entièrement cette classe d’erreur.

4

Salut @Kalon
Si les deux identifiants sont du type OAuth2 géré « Se connecter avec Google », ils passent par le client Google partagé de n8n sur Cloud, ce qui explique pourquoi deux comptes différents échouent dans la même fenêtre et pourquoi vous n’avez pas de tableau de bord API à consulter. Recréez l’identifiant en tant qu’OAuth2 personnalisé en utilisant un client de votre propre projet Google Cloud et pointez les deux workflows vers celui-ci. Ouvrez ensuite APIs and Services > Google Sheets API > Metrics dans ce projet : la ventilation des codes de réponse indique la raison que Google associe à chaque 503, et vos interrogations s’exécutent sur votre propre client au lieu d’un client partagé.

5

L’erreur 503 provient du côté de Google, pas de n8n — et sur n8n Cloud, le Sheets Trigger utilise le client Google OAuth partagé de n8n, donc vous partagez le quota API de ce client avec tous les autres utilisateurs de Cloud. Quand Google ralentit ce projet partagé, vous obtenez des 503 intermittentes même si vos propres identifiants et volume sont corrects. C’est pourquoi cela affecte les deux workflows avec des identifiants différents en même temps, et pourquoi Retry On Fail ne le résout pas — un trigger de polling ne relit pas les lignes qu’il a ignorées pendant les cycles échoués, donc le vrai risque ici est des lignes silencieusement manquées, pas la ligne d’erreur elle-même.

Deux solutions, par ordre d’impact :

  1. Passer à Custom OAuth2 — créez votre propre projet Google Cloud + client OAuth et utilisez-le comme identifiant. Cela vous enlève du quota partagé pour vous mettre sur le vôtre, ce qui élimine généralement les 503 intermittentes d’un coup.

  2. Remplacer le polling par un push — un trigger onChange de Google Apps Script qui envoie les nouvelles lignes en POST à un Webhook n8n. Pas de polling signifie pas de fenêtre de lignes manquées (enveloppez le côté Apps Script dans un try/catch, puisqu’il a ses propres quotas).

Dans les deux cas, ajoutez un petit filet de sécurité : un workflow planifié toutes les 15–30 min qui relit l’heure précédente de lignes et déduplique sur l’id de ligne ou une colonne de timestamp — donc tout ce qui est tombé pendant une fenêtre 503 sera quand même récupéré.

6

L’explication du shared-OAuth-client ci-dessus est très probablement correcte, et passer à un client personnalisé est la bonne étape suivante. Mais tout le monde ici (moi compris, jusqu’à ce que je relise votre message) débat sur quel sondage corriger, et je pense que la question la plus utile est pourquoi vous sondez du tout.

rowAdded à un intervalle de 60 secondes, c’est n8n qui demande à Google « est-ce que quelque chose a changé ? » 1 440 fois par jour, par workflow, indéfiniment — et la grande majorité de ces appels ne retournent rien. Chacun d’eux est une occasion de recevoir un 503, et passer à votre propre client OAuth réduit cette exposition sans l’éliminer, parce que 503 est ce que le backend de Google retourne sous charge quel que soit le client auquel vous appartenez.

Poussez au lieu de sonder. Dans la feuille : Extensions → Apps Script, puis quelque chose comme :


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

...lié comme un déclencheur installable (Triggers → Add Trigger → On change, ou On form submit si les lignes arrivent d'un formulaire). Dans n8n, remplacez le Sheets Trigger par un nœud Webhook.

Ce que cela vous apporte : **zéro appel à l'API Sheets**, donc la classe entière de défaillances que vous chassez disparaît plutôt que de devenir plus rare. Apps Script s'exécute *à l'intérieur* de Sheets et ne touche pas à l'API REST Sheets ou son quota, donc un 503 d'API Google ne peut pas perdre votre événement. C'est aussi instantané au lieu de jusqu'à 60 secondes de retard, et cela ne coûte rien.

Deux avertissements honnêtes, car ce n'est pas gratuit :

- `onChange` ne se déclenche pas pour les modifications effectuées par *d'autres* écritures API ou scripts. Si certaines lignes arrivent via l'API Sheets plutôt que par un humain ou un formulaire, elles ne le déclencheront pas — vérifiez comment les lignes arrivent réellement avant de vous engager.
- Vous dépendez maintenant de votre webhook étant accessible. Apps Script ne fera pas de nouvelles tentatives significatives, donc un redémarrage de n8n pendant un POST perd cet événement.

C'est pourquoi le balayage de filet de sécurité suggéré ci-dessus reste indépendamment du déclencheur que vous utilisez : un workflow programmé qui relit les N dernières lignes et déduplique sur un identifiant de ligne. Poussez pour la latence, balayez pour la correctitude. Cette combinaison est ce que j'exécuterais en production, et c'est ce qui fait de « ai-je silencieusement manqué une ligne pendant une fenêtre 503 ? » une question à laquelle vous pouvez réellement répondre au lieu de supposer.

Une dernière chose à vérifier avant de poursuivre : pendant ces fenêtres de défaillance, des lignes ont-elles réellement été *manquées*, ou le prochain sondage réussi les a-t-il reprises ? Les 503 sont bruyants et ennuyeux, mais la perte de données silencieuse est ce qui vous ferait vraiment du mal, et il vaut la peine de confirmer lequel vous aviez.
7

@Kalon
L’erreur 503 Service Unavailable dans n8n (Google Sheets Trigger) indique un problème temporaire du côté du serveur de destination — dans ce cas, l’API Google Sheets est temporairement incapable de traiter la demande.

Les causes et solutions peuvent être décomposées comme suit :

Qu’est-ce qui provoque cette erreur ?

  1. Surcharge des serveurs Google ou indisponibilité temporaire (erreur transitoire) : C’est la cause la plus commune. Les serveurs de Google pourraient redémarrer, subir une maintenance, ou gérer un volume de trafic inhabituellement élevé à ce moment précis.

  2. Interrogation trop fréquente : Le workflow vérifie les mises à jour chaque minute. L’exécution d’un déclencheur de polling à cette fréquence élevée peut amener l’API Google à considérer les demandes comme trop agressives, déconnectant temporairement la connexion pour éviter une surcharge (même si elle ne retourne pas explicitement une erreur 429 Too Many Requests).

  3. Problèmes réseau intermittents : Il pourrait y avoir une brève perte de connectivité ou un dépassement du délai d’établissement de la connexion entre votre instance n8n et les serveurs de Google.

Comment corriger le problème ?

1. Activer « Retry On Fail » (comme recommandé par le système) C’est le moyen le plus efficace de gérer ces types d’erreurs transitoires.

  • Accédez aux Paramètres du nœud (icône d’engrenage) du Google Sheets Trigger.

  • Activez Retry On Fail.

  • Configurez le nombre de tentatives (par exemple, 3 fois) et le délai d’attente entre les tentatives. Cela empêche le workflow de s’arrêter immédiatement en cas d’erreur 503 temporaire.

2. Augmenter l’intervalle de polling Si votre déclencheur vérifie les données trop fréquemment (par exemple chaque minute), envisagez d’augmenter l’intervalle pour réduire la charge globale de l’API.

  • Modifiez l’intervalle pour vérifier toutes les 5 minutes ou 15 minutes si les mises à jour en temps réel ne sont pas strictement nécessaires pour votre cas d’usage.

3. Vérifier les quotas de la Google Cloud Console Si vous utilisez vos propres identifiants OAuth2 personnalisés (plutôt que les identifiants cloud par défaut de n8n) :

  • Connectez-vous à la Google Cloud Console et vérifiez la section Quotas pour l’API Google Sheets afin de vous assurer que vous ne dépassez pas les limitations par minute ou par jour.

4. Vérifier le statut du service Google Parfois, Google Workspace lui-même connaît des perturbations. Vous pouvez surveiller la santé en temps réel de ses services sur le tableau de bord du statut de Google Workspace. Si Google connaît une panne généralisée, vous devrez simplement attendre que son équipe résolve le problème.

8

Je pense qu’il y a quelques choses qui se mélangent ici.

Un 503 est généralement une défaillance passagère du côté de Google, mais je ne le regrouperais pas automatiquement avec les problèmes de quota ou le sondage agressif. Si Google pense que vous dépassez les quotas, vous voyez normalement des réponses 429 ou 403 liées aux quotas, pas 503.

De plus, je ne suis pas convaincu que l’activation de Retry On Fail soit nécessairement la réponse ici si la défaillance se produit au niveau du sondage des déclencheurs eux-mêmes. Les nœuds de déclencheur se comportent différemment des nœuds de flux de travail ordinaires, il serait donc utile de confirmer si les tentatives s’appliquent réellement aux défaillances de sondage de Google Sheets Trigger ou uniquement aux exécutions de nœuds en aval.

L’explication OAuth partagée semble beaucoup plus plausible, surtout que plusieurs utilisateurs semblent rencontrer ce problème à peu près au même moment. La migration vers un client OAuth personnalisé vous isole du comportement des clients partagés et c’est probablement la première chose que je testerais.

Cela dit, je pense que la question la plus importante est celle qu’Adam a soulevée plus tôt :

Est-ce que quelque chose a vraiment été perdu ?

Des lignes ont-elles été manquées de façon permanente, ou le prochain sondage réussi s’est-il simplement rattrapé et les a traitées normalement ?

Parce qu’il y a une grande différence entre :

  • des erreurs 503 transitoires bruyantes dans les journaux, et
  • une perte de données silencieuse.

La première est ennuyeuse.

La deuxième est un problème de production.

Concernant la suggestion Apps Script, il y a un détail important à mentionner :

e.range et e.values fonctionnent pour certains types de déclencheurs tels que On form submit, mais ils ne sont pas garantis d’exister pour un déclencheur installable générique On change. Donc l’implémentation d’exemple peut fonctionner parfaitement pour certains flux de travail et échouer immédiatement pour d’autres selon la manière dont les lignes entrent dans la feuille.

L’approche webhook est toujours attrayante car éliminer le sondage élimine toute la classe des défaillances de sondage, mais elle introduit un mode de défaillance différent à la place :

si le point de terminaison webhook est indisponible lors de la livraison, Apps Script ne vous offrira ni tentatives durables ni mise en file d’attente.

Personnellement, j’utiliserais :

  • la livraison push/webhook pour une faible latence,
  • le traitement idempotent à l’aide d’un identifiant de ligne,
  • et un flux de travail de réconciliation planifiée qui revérifie régulièrement les lignes récentes.

Push pour la vitesse.

Balayage pour la correction.

Cette combinaison résiste aux hoquet d’API, aux arrêts de webhook, aux redémarrages de flux de travail et à pratiquement tous les cas limites désagréables qui finissent par survenir en production.

À ce stade, je serais intéressé par trois choses avant de tirer des conclusions :

  1. OAuth n8n partagé ou OAuth personnalisé ?
  2. Des lignes ont-elles réellement été manquées ?
  3. Tous les utilisateurs affectés utilisent-ils la même région ou infrastructure n8n Cloud ?

Ces réponses nous disent probablement si nous sommes face à des défaillances transitoires attendues de Google ou à un incident réel du côté d’n8n qui mérite une enquête plus approfondie.

9

Bonjour Kalon,

Une erreur 503 Service Unavailable indique généralement que le serveur de l’API Google Sheets est temporairement surchargé ou applique des limites de débit strictes en raison d’une concurrence élevée.

Comme tu interroges toutes les minutes sur plusieurs flux de travail distincts et avec des identifiants OAuth différents, il est très probable que tu déclenches les quotas de requêtes concurrentes de Google, ce qui les amène à rejeter les requêtes de manière intermittente. Puisque « Retry on Fail » avec des délais courts par défaut ne le détecte pas, la durée du blocage dépasse les tentatives de nouvel essai.

Voici deux façons de résoudre définitivement ce problème :

  1. Interrogation dynamique et backoff exponentiel (correction rapide) :
    • Accède aux paramètres du nœud Google Sheets → Sous « Retry on Fail », augmente le nombre de tentatives maximales à 5.
    • Augmente le délai de nouvel essai (temps d’attente) à au moins 5000 ms ou 10000 ms. Cela donne à l’API Google suffisamment de temps de refroidissement entre les tentatives pour absorber le blocage transitoire 503.

  2. Passer de l’interrogation à une architecture basée sur les webhooks (recommandé :rocket:) :
    Au lieu de faire interroger Google Sheets par n8n toutes les minutes, tu peux inverser l’architecture.
    • Remplace le déclencheur Google Sheets par un nœud Webhook n8n.
    • Ajoute un simple script Google Apps Script de 5 lignes (déclencheur onEdit) à ta feuille Google Sheets qui envoie automatiquement une requête POST à ton webhook n8n chaque fois qu’une nouvelle ligne est ajoutée.

Cela contourne complètement les limites de débit d’interrogation, élimine entièrement les erreurs 503 et économise une énorme quantité de surcharge d’exécution d’n8n.

Fais-moi savoir si tu as besoin d’aide pour structurer la configuration du script Google Apps Script, je peux te partager le bloc de script !