Start with the hostname. Trouble on GitLab.com and trouble on a company-operated GitLab instance are not the same incident. A status notice about the public service cannot tell you whether your organization's own server is healthy.
The official GitLab System Status page covers GitLab.com and associated services. It explicitly distinguishes that scope from other installations. Read it for current public-service updates, then compare the relevant component with your error. This guide provides a diagnostic process rather than a live status claim.
Am I using GitLab.com or a separate installation?
Look at the browser address and your repository's remote address. Check them locally without pasting credentials into a chat. If your team uses a separate hostname, consult its internal service owner or status channel as well as any relevant external dependency notices.
For a self-managed instance, collect the failed operation and ask whether other users can reproduce it. An unavailable database, reverse proxy or runner in your environment needs your team's investigation. The absence of a GitLab.com incident is not evidence that your installation works.
If you use a managed offering with a separate support process, follow that process. Do not assume every GitLab-branded service has the same status scope or recovery path. The hostname and account context should remain part of the incident note.
Is the problem shared beyond my account?
Ask a colleague to attempt the same action in the same project using their own permissions. Compare another project you are authorized to access. If one project fails while others work, investigate project access and configuration alongside any provider notice.
Try a permitted alternative network when the symptoms suggest connectivity. Several people in one office can share a proxy or DNS issue. A comparison from another location is useful, but keep the requested operation the same so the result is meaningful.
Record the time, client and error text. Note whether the web interface, Git transport and API behave differently. Those differences help you narrow the fault instead of labeling every project problem as “GitLab down.”
Which component should I inspect?
GitLab's public status page separates website, API, Git operations, registries and CI/CD services. Find the component nearest to your failed action and read the incident notes for its specific scope.
| Symptom | Useful checks |
|---|---|
| Clone, fetch or push fails | Git operations, remote address and authentication. |
| Project or merge request will not load | Website, project access and another authorized user. |
| API automation fails | Response details, credentials and API status. |
| Pipeline waits without starting | Job eligibility, runner availability and CI coordination. |
| Image or package cannot download | Correct registry, package access and the failing request. |
A single pipeline can depend on all of these. Find the first failed step in its log. Later failures may be consequences rather than separate incidents.
Does a pending pipeline mean GitLab CI is down?
Not necessarily. Determine whether a pipeline exists, whether the job is eligible to run and whether an appropriate runner can take it. A manual action, tag mismatch or unavailable runner can leave work waiting without a platform-wide outage.
GitLab's runner documentation explains that runners execute CI/CD jobs and have different management arrangements. Your own runner's machine and network are separate things to inspect from GitLab's service status.
If the job starts and then fails, read the step output. A package download error may point to a registry, and a deployment error may point to your hosting environment. Repeatedly restarting the whole pipeline loses that distinction and can repeat successful steps.
What if Git works but packages do not?
Reading repository history does not test a container registry or package registry. Compare the hostname, package or image reference, authentication method and operation. A successful public download does not prove your private package access is valid.
If the log shows npm as the destination, consult Is npm down?. If it shows your organization's own registry, check that service's owner and health. Do not replace registry settings simply because a pipeline ran on GitLab.
For failed publishing, keep the intended version or tag and any server response. A timeout can leave the result uncertain. Verify the registry state when possible before publishing again or changing the release version.
How do official status and public reports compare?
Official notices describe the provider's acknowledged incident and recovery progress. Downdetector and social posts can help identify simultaneous complaints, but they do not distinguish every installation, component or account type reliably.
Look for reports with the same hostname, time and symptom. A self-managed server outage at one company is not evidence that GitLab.com is down for everyone. Conversely, a green public headline does not invalidate a reproducible problem. Read why status pages can disagree with users for the common reasons.
What does partial availability mean for my team?
A partial outage can affect one component or a subset of requests while other operations work. It may block your entire release process even if most users can still browse projects. Read the incident's boundary instead of deciding impact from its color.
Once you have identified the blocked action, use the GitLab outage playbook. Continue local work where possible, keep a record of unfinished jobs and verify the original operation after recovery. Your team's definition of recovered should include the pipeline or release it actually needs.