--- title: "Reducing GitLab Resource Usage by Disabling Built-In Monitoring Services" date: 2026-08-03T23:14:01.000Z author: Z.SHINCHVEN tags: [GitLab, Docker, Prometheus, Self-hosting, Performance] canonical: https://atlassc.net/2026/08/04/reducing-gitlab-resource-usage-by-disabling-built-in-monitoring-services --- # 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`: ```yaml 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: ```bash 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: ```bash docker exec -it gitlab-ce gitlab-ctl status ``` The output should no longer list monitoring services such as: ```text prometheus alertmanager node-exporter postgres-exporter redis-exporter gitlab-exporter ``` Core GitLab services should still be running, including services such as: ```text 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: ```bash docker stats --no-stream gitlab-ce ``` To inspect the largest processes inside the container: ```bash 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: ```bash 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: ```bash 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 - [Monitoring GitLab with Prometheus](https://docs.gitlab.com/administration/monitoring/prometheus/) - [Running GitLab in a memory-constrained environment](https://docs.gitlab.com/omnibus/settings/memory_constrained_envs/) - [Back up GitLab running in a Docker container](https://docs.gitlab.com/install/docker/backup/)