When are GitLab performance reviews? (2026)
GitLab runs a documented, handbook-first assessment process where written evidence outweighs hallway reputation. Exact cycle dates vary by year and org, so the reliable move is to keep a running record your manager can read without you in the room.
Once a year
No specific review month is published for this company, because none could be sourced from the company's own material. What follows is the cycle shape, which is what is actually knowable. Your own manager is the authority on this year's dates.
How the cycle works
GitLab is an all-remote company that writes down how it operates, and its assessment process inherits that habit. The handbook is the operating manual: process, expectations, and the shape of the conversation are published rather than passed along verbally by whoever has been there longest. If you want to know what your manager is filling in, you can go read the form.
The practical consequence of all-remote is that almost nothing about your work is observed incidentally. Nobody notices you staying late, catching a bad deploy, or unblocking someone in a hallway. What exists is what got written: merge requests, issue threads, handbook edits, incident notes, Slack. Your assessment is assembled from artifacts, which means the artifact trail is the performance record.
Exact cycle dates move year to year and differ by department, so treat any month you hear secondhand as unreliable. Ask your manager for this cycle's dates directly, and ask early enough that the answer is still useful.
What actually gets weighed
Written contribution carries unusual weight here. A handbook page you authored that other teams now follow is a durable, citable artifact in a way a well-received meeting comment is not. So is a well-argued issue that changed a direction, a runbook that shortened an incident, or a merge request that removed a category of bug rather than one instance of it.
Because the company is distributed across many time zones, asynchronous unblocking is a real axis of impact. Someone who leaves a review comment detailed enough that a colleague eight hours away can act on it without a follow-up call has saved a day of calendar time. That is worth naming explicitly.
Iteration is a stated company value, and it shows up in evaluation as a preference for shipped, small, sequential improvements over a large project held back for polish. If your year is one big launch, be ready to describe the intermediate steps that de-risked it.
What to have ready
- A list of merge requests and issues where you changed the outcome, not just the code, with a one-line note on what would have happened otherwise.
- Every handbook or documentation page you authored or materially rewrote, and any evidence another team adopted it.
- Incidents you were part of: what you did, what the resolution time was, what changed afterward so it would not recur.
- Concrete instances of asynchronous unblocking — the person, the problem, the time zone gap you closed.
- Any scope you took on that nobody assigned to you.
Keeping this current through the year is far cheaper than reconstructing it from a year of Git history the week the form opens.