Reducing GitLab Resource Usage by Disabling Built-In Monitoring Services
I run GitLab CE in Docker on a relatively small Ubuntu server with four CPU cores and about 8 GB of memory. The server occasionally became completely unresponsive: CPU usage reached 100%, and even SSH stopped responding. After enabling atop and reviewing its historical logs, I found that GitLab's built-in monitoring stack was contributing significant CPU, memory, and disk I/O load.
If you do not use GitLab's built-in monitoring dashboards or Prometheus-based alerts, disabling this stack is a practical way to reduce background resource consumption without losing normal GitLab functionality.
Quick Configuration
Add the following settings to your existing GITLAB_OMNIBUS_CONFIG block in docker-compose.yml:
services:
gitlab:
image: gitlab/gitlab-ce:latest
container_name: gitlab-ce
restart: always
environment:
GITLAB_OMNIBUS_CONFIG: |
external_url 'https://gitlab.example.com'
prometheus_monitoring['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
node_exporter['enable'] = false
postgres_exporter['enable'] = false
redis_exporter['enable'] = false
gitlab_exporter['enable'] = false
sidekiq['metrics_enabled'] = false
puma['exporter_enabled'] = false
Keep the rest of your existing GitLab configuration in the same block. Do not replace it with this example.
Apply the change:
docker compose up -d
Compose should recreate the GitLab container when it detects the changed environment configuration. GitLab then reconfigures its packaged services during startup.
What These Services Do
The built-in monitoring stack collects and stores metrics from GitLab and its supporting services:
- Prometheus scrapes and stores time-series metrics.
- Alertmanager processes alerts produced from Prometheus rules.
- Node Exporter reports operating-system and host metrics.
- PostgreSQL Exporter reports database metrics.
- Redis Exporter reports Redis metrics.
- GitLab Exporter exposes application and database-related metrics.
- Sidekiq metrics expose background-job metrics.
- Puma's exporter exposes web application metrics through a dedicated metrics process.
GitLab's documentation states that Prometheus and its exporters are enabled by default in Linux package installations. It also documents prometheus_monitoring['enable'] = false as the umbrella setting for disabling Prometheus and its exporters, including exporters added in future releases.
The individual enable settings in the example make the intended configuration explicit and match GitLab's recommendations for memory-constrained environments.
What Continues to Work
Disabling the monitoring stack does not disable the components that provide GitLab's core features. The following functionality remains available:
- Repository hosting
- Git push and pull over SSH or HTTPS
- The GitLab web interface and API
- CI/CD jobs and runners
- PostgreSQL and Redis
- Gitaly repository storage
- Sidekiq background jobs
- Scheduled GitLab backups
Only GitLab's bundled metrics collection, Prometheus data storage, monitoring dashboards, and related alerts are removed. If you use an external Prometheus installation, first confirm that it does not depend on these exporters.
Verify the Running Services
After the container finishes starting, inspect its supervised services:
docker exec -it gitlab-ce gitlab-ctl status
The output should no longer list monitoring services such as:
prometheus
alertmanager
node-exporter
postgres-exporter
redis-exporter
gitlab-exporter
Core GitLab services should still be running, including services such as:
gitaly
gitlab-kas
gitlab-workhorse
nginx
postgresql
puma
redis
sidekiq
sshd
The exact list can vary by GitLab version and by features enabled in your installation.
Measure the Result
Check the container's current resource usage:
docker stats --no-stream gitlab-ce
To inspect the largest processes inside the container:
docker exec gitlab-ce \
ps -eo pid,rss,comm --sort=-rss | head -20
For a more useful comparison, record CPU, memory, and disk I/O before the change and again after GitLab has been running under a similar workload. A single docker stats snapshot may miss periodic activity such as Prometheus compaction.
GitLab reports an observed memory reduction of about 300 MB from disabling monitoring as part of its guidance for memory-constrained environments. Your result will vary. On a small server, the larger benefit may be fewer disk writes, less Prometheus database compaction, and lower metric collection overhead rather than memory savings alone. These improvements can be especially valuable on low-performance cloud disks.
Backups Are Unaffected
GitLab's backup system is independent of Prometheus and the exporters. You can still create a backup with:
docker exec -t gitlab-ce gitlab-backup create
Disabling monitoring does not create or change a backup schedule. Backups still depend on your existing cron job, systemd timer, or external automation.
The application backup is only part of a complete recovery plan. Back up the following separately as applicable:
gitlab-secrets.json- Docker Compose configuration
- TLS certificates and keys
- Host-mounted GitLab volumes
- Any configuration that exists outside the GitLab application backup
When configuration is supplied through GITLAB_OMNIBUS_CONFIG, GitLab notes that those values are not written to gitlab.rb. Your Compose file therefore becomes an important part of the configuration backup.
Re-enable Monitoring Later
If you need GitLab's built-in dashboards or alerts later, remove the overrides or change the required values back to true, then run:
docker compose up -d
Prometheus will begin collecting new metrics after it starts. Historical data is available only if its data directory was retained.
Conclusion
GitLab's bundled monitoring stack is valuable when you actively use its metrics and alerts, but it is not essential to repository hosting, the web interface, CI/CD, or backups. On a small self-hosted instance, disabling unused monitoring services can remove a meaningful amount of background work and make the server more responsive without sacrificing core GitLab functionality.
References
