GitLab Geo with a unified URL

Latency-based routing answers each DNS query with the site that has the lowest measured network latency from the resolver that asked. It fits organizations whose users are spread across regions and who want the closest working site to serve them during normal operation. Because a Geo secondary is a warm standby that is continuously synchronized, a read-heavy team may be served from a nearby site while writes still go to the primary, so confirm how your users will actually reach the primary before relying on latency alone.

• Normal-state fit: suits distributed teams where latency differences between sites are meaningful to users.
• Health checks: when a site fails its health check, its record is withdrawn from answers, so new queries go to the remaining sites.
• Nearest site down: users whose resolver is closest to the failed site receive the next-lowest-latency answer, which may add delay until caches expire.
• Resolver location: latency is measured from the resolver, not the user, so confirm how your provider handles large public resolvers.
• Write traffic: confirm with GitLab Geo documentation which operations are proxied to the primary, since this decides whether latency routing helps your users.

Before choosing this policy, ask your DNS provider to document how it measures latency and how health check results propagate to answers.

Geolocation routing answers queries based on the geographic location of the resolver or client, mapping countries, continents or regions to specific sites. It fits organizations with data residency or policy requirements that dictate which region's users may reach which site, and it gives administrators predictable mapping rather than measured performance. The trade-off is that geographic maps can be out of date, and a user traveling or using a remote VPN may be sent to a site that is not the closest.

• Predictable mapping: each region is pinned to a named site, which is easier to explain to auditors and regional administrators.
• Default record: most providers require a default answer for locations not in the map, so define which site serves unmapped regions.
• Health checks: an unhealthy site can be removed from its region's answer, but confirm whether the provider falls back to the default or returns no answer.
• Nearest site down: users in the mapped region receive the fallback you configured, which may be a distant site with higher latency.
• Map maintenance: plan an owner for updates when network ranges or regional rules change.

Ask the provider how geolocation data is sourced and how often it is refreshed.

Failover routing uses a primary record and a secondary record. Queries receive the primary answer while its health check passes and switch to the secondary when it fails. This matches the Geo model of one primary site and one or more standby secondaries, and it is the simplest policy to reason about during an incident. It does not spread normal traffic across sites, so the standby is not used to serve everyday users.

• Fit: suits a single primary site with a designated disaster recovery secondary, where failover is the main goal.
• Health checks: the health check decides when failover happens, so its endpoint, interval and failure threshold must reflect real GitLab availability, not just a open port.
• Nearest site down: users switch to the secondary once the record changes, but clients may keep cached answers until their TTL expires.
• Promotion coupling: DNS failover does not promote the secondary. Confirm the promotion procedure in the GitLab Geo documentation and the runbook for it.
• Failback: decide whether traffic returns automatically when the primary recovers, and who approves it.

Test the health check against a real GitLab sign-in and Git operation before relying on it.

Weighted records return a share of answers to each site according to configured weights, and multi-value answers return several addresses for clients to choose from. These can spread load or support gradual cutovers, but neither understands whether GitLab on a site is ready to serve writes. They fit transition periods, such as moving a hostname between sites, more than steady-state Geo routing.

• Gradual cutover: shifting weights lets an operator move a portion of traffic and watch results before a full switch.
• Session effects: a user whose requests land on different sites mid-session may see inconsistent state if replication lag exists.
• Health checks: unhealthy records may still be returned if health checking is not enabled for them, so verify this setting.
• Nearest site down: clients fall through to other addresses, but many do not retry immediately, which can look like slow sign-in.
• Operational clarity: weights are easy to forget, so document the intended steady state after every change.

Before a cutover, confirm with the provider how weighted answers interact with your health checks and TTLs.

The right policy depends on whether your sites are active for users or one is a standby. In a primary and secondary design, failover is usually the clearest choice. In a design where several sites accept user traffic, latency or geolocation routing may fit better, but the GitLab Geo model must still define which operations reach the primary. Choosing a policy is not finished until a team has tested what happens during a site outage and recorded the expected user experience.

• Define the steady state: write down which site serves which users under normal conditions.
• Define the outage state: state what each user group should see when their nearest site is down.
• Test health checks: simulate a failed site and confirm the record changes as intended.
• Measure client caching: confirm with your own resolvers how long answers persist after a change.
• Assign ownership: name who changes records, who approves failback and who checks the result.

Ask your DNS provider and your GitLab Geo design review to sign off on the chosen policy in writing.