What causes "Sourcegraph Search Slow or Timing Out (Zoekt Crash Loop)"?

Overloaded gitserver Too little indexed-search memory or CPU vm.max_map_count too low for the repos per replica Zoekt watchdog restarts under sustained load

How do I fix "Sourcegraph Search Slow or Timing Out (Zoekt Crash Loop)"?

1. Narrow the cause: Try the query with index:only, timeout:60s and count:all Check the Grafana Git Server dashboard; a healthy node stays below 5ms on the echo test 2. Fix zoekt-webserver CrashLoopBackOff: Confirm pods are not simply OOMKilled (kubectl top pod) Check sudo sysctl -n vm.max_map_count; if below twice (repos / indexed-search replicas), raise it, for example sysctl -w vm.max_map_count=262144 Persist it in /etc/sysctl.conf, or add replicas 3. Add resources: Raise indexed-search memory and CPU, or add shards on Kubernetes Follow the resource estimator

Sourcegraph Search Slow or Timing Out (Zoekt Crash Loop)

Workaround available Self-hosted Updated November 14, 2026Based on 2 user reportsHow we research

Quick answer

Slow or timed-out search on a self-hosted instance is usually undersized gitserver or indexed-search, or zoekt-webserver hitting vm.max_map_count.

Most likely fix: Narrow the cause

How to fix it

Try these in order — the most common fix is first.

1. Narrow the cause
1. Try the query with index:only, timeout:60s and count:all
2. Check the Grafana Git Server dashboard; a healthy node stays below 5ms on the echo test
Did this fix it?
2. Fix zoekt-webserver CrashLoopBackOff
1. Confirm pods are not simply OOMKilled (kubectl top pod)
2. Check sudo sysctl -n vm.max_map_count; if below twice (repos / indexed-search replicas), raise it, for example sysctl -w vm.max_map_count=262144
3. Persist it in /etc/sysctl.conf, or add replicas
Did this fix it?
3. Add resources
1. Raise indexed-search memory and CPU, or add shards on Kubernetes
2. Follow the resource estimator
Did this fix it?