GitLab est-il en panne ?

Comprendre la disponibilité de GitLab.com

La disponibilité de GitLab.com ne se résume pas à un simple oui ou non. L’interface web, l’authentification, l’accès aux projets, la consultation des dépôts, le clonage, le fetch et le push peuvent tomber en panne indépendamment les uns des autres. Une page qui se charge correctement ne garantit pas que l’opération Git ou le projet dont vous avez besoin fonctionne.

Consultez la page de statut officielle de GitLab pour connaître les incidents et maintenances en cours. Comparez le composant affecté et le moment de l’incident avec l’action précise qui a échoué :

• Un incident correspondant rend plus probable une cause liée à GitLab. Évitez de répéter les opérations d’écriture jusqu’à ce que vous sachiez si le push, le merge ou une autre opération initiale a abouti.
• Si aucun incident pertinent n’est indiqué, comparez le problème entre plusieurs navigateurs, appareils, comptes, projets ou réseaux avant de conclure que GitLab est indisponible.
• Un problème limité à un seul projet, dépôt, compte, client Git ou réseau indique généralement un problème d’autorisations, d’identifiants, de configuration ou de connectivité locale plutôt qu’une panne généralisée du service.

Cette page concerne GitLab.com. Les installations GitLab self-managed disposent d’une infrastructure et d’une configuration distinctes ; une mise à jour du statut de GitLab.com ne décrit donc pas automatiquement leur disponibilité.

Résoudre les problèmes liés à GitLab

1. Recherchez un incident GitLab correspondant

Ouvrez la page de statut officielle de GitLab et comparez tout incident ou événement de maintenance actif avec la fonction GitLab qui a échoué. Examinez le composant affecté et l’horaire indiqué, pas seulement le fait que la page d’accueil s’ouvre.

Si l’incident correspond à votre symptôme, notez l’erreur exacte et attendez une mise à jour plutôt que de réessayer constamment. Pour un push, un merge ou toute autre opération d’écriture, vérifiez d’abord si l’action initiale a abouti.

2. Testez le navigateur et la session

Si GitLab fonctionne dans une fenêtre privée, un autre navigateur ou sur un autre appareil, la cause est probablement locale au profil ou à la session du navigateur d’origine. Essayez :

• De recharger la page concernée et de vous reconnecter lorsque seules les pages authentifiées échouent.
• Une fenêtre privée ou un autre navigateur.
• De désactiver temporairement les extensions qui modifient les scripts, les cookies, les contrôles de confidentialité ou les requêtes.
• D’effacer les données du site pour gitlab.com si la page est vide, redirige en boucle ou revient à l’écran de connexion.

Si le même problème survient sur plusieurs navigateurs et appareils, une cause spécifique au navigateur devient moins probable.

3. Comparez les réseaux et l’accessibilité DNS

Les délais d’attente, refus de connexion, échecs DNS, erreurs de proxy et filtrages peuvent empêcher le chargement de GitLab.com même lorsque le service fonctionne normalement. Si possible, comparez la connexion concernée avec un autre réseau fiable, comme un partage de connexion mobile.

• Fonctionne sur un autre réseau : recherchez un problème de DNS local, de pare-feu, de proxy, de VPN ou de filtrage d’entreprise.
• Échoue sur tous les réseaux : consultez la page de statut et déterminez si le problème est limité à un compte ou à une opération particulière.
• Fonctionne dans un navigateur mais pas dans Git : examinez l’URL distante du client, les identifiants, le proxy et la configuration SSH ou HTTPS.

4. Vérifiez l’accès au compte et au projet

Lorsque GitLab se charge mais qu’un seul projet ou dépôt ne peut pas être ouvert, cloné, récupéré ou mis à jour, vérifiez que vous êtes connecté au compte prévu et que vous disposez toujours des autorisations nécessaires pour accéder à ce projet. Un accès refusé pour un seul dépôt n’est pas la même chose qu’un GitLab inaccessible pour tout le monde.

En cas d’échec d’authentification, vérifiez l’URL distante et la méthode d’identification configurée. Ne partagez pas de jetons d’accès ni de clés privées dans des demandes d’assistance ou des rapports de problème publics.

5. Interprétez l’erreur sans supposer une panne

• Réponse 5xx : peut indiquer un problème côté GitLab, mais un proxy ou une passerelle peut également l’avoir générée. Consultez la page de statut et comparez avec un autre réseau.
• Délai d’attente de connexion dépassé : indique souvent un problème de chemin réseau, de pare-feu, de proxy, de DNS ou d’accessibilité temporaire.
• Connexion refusée : un point de terminaison ou un intermédiaire a rejeté la connexion ; comparez les résultats dans le navigateur, le client Git et sur un autre réseau.
• Avertissement TLS ou de certificat : vérifiez l’adresse, l’horloge du système, le navigateur, le proxy et les logiciels de sécurité. Ne contournez pas les avertissements de certificat lors de l’accès à des identifiants ou dépôts GitLab.

Lorsque vous transmettez le problème, indiquez l’heure, l’URL GitLab ou l’opération concernée, le texte exact de l’erreur, la présence éventuelle d’un incident sur la page de statut et le résultat obtenu avec un autre navigateur ou réseau.