SRE at GitLab in 2026: Fully-Remote, Handbook-First, Formula-Based Comp

SRE at GitLab in 2026: fully-remote + handbook-first

SRE at GitLab is shaped by two organizational facts rare among peer companies. First, GitLab has been fully-remote since founding in 2014. No headquarters, no flagship office, no hybrid expectation. Engineers work from whatever timezone they live in, and team meetings are scheduled with that constraint as the input. Second, GitLab runs on a public Engineering Handbook. Every team charter, runbook, SLO definition, incident severity policy, and interview rubric is written down at about.gitlab.com/handbook and updated through merge requests against the handbook repository.

The Infrastructure department lives at about.gitlab.com/handbook/engineering/infrastructure. Reliability engineers sit on sub-teams aligned to the production surfaces they own (Datastores, Foundations, Delivery, Observability, Scalability, and similar), each with a public charter and public escalation runbooks. New hires can read the team's actual operating model on day zero.

Communication defaults to async. Slack is the low-latency coordination layer, but the durable record is always an issue, a merge request, or a handbook page. Meetings are recorded, agendas are written before the call, and decisions get written back into the handbook after the call. For an SRE this matters because incident reviews, SLO renegotiations, and capacity planning conversations all have a written-first trail an engineer in any timezone can pick up without backchannel context. The cost is that real-time-culture engineers find the cadence slower; the benefit is that nothing important lives only in someone's head.

Interview process

The SRE interview loop at GitLab is structured, documented in the Hiring section of the Handbook, and runs entirely over Zoom across the candidate's timezone. There is no on-site expectation. The standard loop for a senior SRE role in 2026 is roughly:

• Recruiter screen (30 min): background, level calibration, target sub-team, compensation expectations against the published formula, timezone overlap with the team you would join.
• Hiring manager interview (45-60 min): career narrative, prior on-call exposure, the kinds of outages you have run incident command on, motivation for joining a fully-remote and all-async organization specifically.
• Technical screen (60 min): a scenario-driven discussion. The interviewer walks you through a production-flavored problem (a queue backing up, a database replica falling behind, a deploy regressing latency) and probes your reasoning, the telemetry you would pull, and the runbook you would write afterward.
• System / reliability design (60 min): a design round on a distributed-systems problem with an operability lens (multi-region failover, error-budget policy, capacity planning, designing an alerting stack from SLOs).
• Peer / cross-functional rounds (2-3 x 45 min): conversations with future peers and an adjacent team lead. Probes collaboration in async, written communication quality, and how you operate when nobody is in the same timezone.
• Executive / skip-level (optional, 30 min): for senior+ roles, a conversation with the engineering leader whose org you would land in.

Two things stand out in practice. The Handbook publishes the interview rubric categories, so candidates prepare against the actual evaluation criteria. And written communication is evaluated as a first-class signal throughout the loop, because at GitLab written communication is the job - a candidate sharp in live conversation but thin in issue comments will struggle in a way they would not at a co-located company. Open requisitions are at about.gitlab.com/jobs.

Compensation by level + region (formula-based)

GitLab's compensation model is documented publicly at about.gitlab.com/handbook/total-rewards/compensation. Base salary for a given role is computed from a published formula: a SF benchmark for the role is multiplied by a level factor (Intermediate, Senior, Staff, Senior Staff, Principal) and a regional location factor that reflects the cost of labor in the candidate's country and metro. A candidate can plug their own region into the formula and compute their own offer band before the first call. There is very little negotiation outside the formula because the formula itself is the offer.

Total compensation has three components: base salary, RSU equity in NASDAQ:GTLB on a four-year vest with a one-year cliff, and a target variable component (SRE roles are non-variable). Equity refresh grants run on the same public formula. Per Levels.fyi 2026 self-reports for GitLab Site Reliability Engineer at levels.fyi/companies/gitlab/salaries/site-reliability-engineer and the SWE benchmark at levels.fyi/t/software-engineer, directional US bands in 2026 land approximately:

• Intermediate SRE (3-5 yrs): total compensation roughly $180K-$240K, base ~$150K-$190K plus GTLB equity grant.
• Senior SRE (5-8 yrs): total compensation roughly $230K-$320K, base ~$180K-$230K plus equity grant that meaningfully shifts with stock price.
• Staff SRE (8-12 yrs): total compensation roughly $300K-$420K, base ~$220K-$275K with equity becoming the dominant component.
• Senior Staff / Principal SRE: total compensation $400K+, heavily equity-weighted.

Regional factors meaningfully shift base. A Senior SRE in San Francisco sits at the SF benchmark; the same role in Berlin, London, or Toronto lands at a defined fraction; in Brazil, Poland, or the Philippines smaller again. Transparency cuts both ways - candidates know their regional factor, but the formula rarely flexes below it. The regional factor table is published in the Total Rewards handbook and updated via merge requests in the open.

Tech stack: Kubernetes + Prometheus + Grafana + Sidekiq + GitLab CI

GitLab.com runs on a stack that is itself documented in the public Infrastructure handbook. The headline components an SRE will operate against day to day are Kubernetes, Prometheus + Grafana, Sidekiq, and GitLab CI.

• Kubernetes on GCP. GitLab.com runs as a set of services on Google Kubernetes Engine. SRE work includes cluster operation, autoscaling policy, node-pool segmentation by workload class, and the control-plane integrations with the Rails monolith and the Go-written supporting services (Workhorse, Gitaly, Praefect).
• Prometheus + Grafana. Telemetry and dashboards. Prometheus is the metrics tier; Grafana is the visualization and SLO dashboard tier. SLOs and error-budget burn-rate alerts are defined in code, reviewed through merge requests against an infrastructure repository, and applied via the standard GitOps flow. Public dashboards exist for the GitLab.com production environment.
• Sidekiq. The Ruby background job system underneath the GitLab Rails monolith. Job queue health (latency, queue depth, retry rate, dead jobs) is a primary SRE telemetry surface because so many user-visible operations on GitLab.com (CI pipeline scheduling, notifications, mirroring, indexing) ride Sidekiq. Operating Sidekiq at GitLab scale - sharding, queue isolation, capacity planning - is one of the named senior SRE skills at the company.
• GitLab CI. Every pipeline that ships a release, a config change, or an infrastructure merge runs on GitLab CI. The company dogfoods its own product as the deployment pipeline for that product. SREs write and review CI configurations as part of the normal change-management flow; there is no separate Jenkins or external CI estate to learn.

Supporting components include PostgreSQL with Patroni for HA (Datastores team), Redis (cache + Sidekiq broker), Consul, HAProxy, GCS, and Cloudflare in front of GitLab.com. Topology, version posture, and runbooks for each are linked from the Infrastructure handbook.