How we supercharged GitLab CI statuses with WebSockets

We just reduced API calls by 92.56% on GitLab's CI job status updates – from 45 million to 3.4 million calls per day. Instead of needing to wait up to half a minute, users now see job status changes instantly. Here's how we did it.

The problem: Polling in 2025

It's 2025, WebSockets are in and polling is out. Polling is more of a legacy method of getting "real-time" updates for software. It's time-driven, meaning clients make network calls to a server on an interval usually between 5 and 30 seconds. Even if the data hasn't changed, those network requests are made to try and get the most accurate data served to the client. WebSockets are event-driven, so you only make network requests to the server when the data has actually changed, i.e., a status in a database column changes from pending to running. Unlike traditional HTTP requests where the client repeatedly asks the server for updates (polling), WebSockets establish a persistent, two-way connection between the client and server. This means the server can instantly push updates to the client the moment something changes, eliminating unnecessary network traffic and reducing latency. For monitoring job statuses or real-time data, this is far more efficient than having clients poll the server every few seconds just to check if anything is different.

The transformation

Previously, the job header on the job log view was utilizing polling to get the most recent status for a single job. That component made a network request every 30 seconds no matter what to try and get the true state of the job.

Our metrics showed that:

• 547,145 network calls happened per 15 minutes
• 45,729,530 network calls happened per 24 hours Users experienced frustrating delays seeing status updates, and we were hammering our database.

Enter GraphQL subscriptions

In comes GraphQL subscriptions with WebSockets. GraphQL subscriptions are a feature that extends GraphQL beyond simple request-response queries and mutations, allowing clients to maintain a real-time connection to the server. While regular GraphQL queries fetch data once and return it, subscriptions let you say 'notify me whenever this specific data changes.' Under the hood, GraphQL subscriptions typically use WebSockets to maintain that persistent connection. Here's what we did:

1. First, we refactored the job header component to use GraphQL for its data
2. Then we implemented a GraphQL subscription to serve real-time updates with ActionCable (Rails' WebSocket framework).

The results

After this implementation, our users now get truly real-time accurate job status – updates appear instantly when jobs change state. The performance gains are remarkable:

• 92.56% reduction in API calls for this component
• Now averaging 39,670 network calls per 15 minutes (down from 547,145)
• Only 3,403,395 network calls per 24 hours (down from 45,729,530) We also monitored CPU utilization and operation rate per command over the last week and have not seen any significant increase on our services. Win-win for the software and the team.

What's next

This is just the beginning. We're working on making every CI status in the GitLab product real-time. Currently, many parts of GitLab's UI still rely on polling to check for updates. Our goal is to systematically replace these polling mechanisms with GraphQL subscriptions, giving users instant feedback across the entire CI/CD workflow. Want to see this capability in action? Check out any job log view and watch those status updates fly. Not a GitLab user yet? Try GitLab Ultimate with GitLab Duo Enterprise for free for 30 days.