## TL;DR
A kernel gateway timeout means the gateway pod could not get a kernel pod running in time: the image is still pulling, the pod is pending on resources, or the gateway URL is wrong. Check `kubectl get events` in the namespace for pull and scheduling delays, and confirm the gateway URL the client uses matches the service. Fix the slow leg (pre-pull the image, raise the timeout, or request fewer resources) rather than retrying blindly.

```text
jupyter kernel gateway timeout starting kernel in kubernetes
```

## Use this when
- Kernel start requests through the gateway time out, but local kernels work.
- Pod events show image pulls or scheduling delays around the timeout.
- The gateway was recently deployed or the image tag changed.

## Not for this skill when
- Kernels start then die. That is a kernel image or env problem.
- The gateway itself is unreachable. That is ingress or service config.

## Steps
1. Check what is slow: `kubectl get events --sort-by=.lastTimestamp -n [namespace] | tail -30`. Verify: you see pull, scheduling, or probe events.
2. Confirm the client URL matches the gateway service: compare the `--gateway-url` or client config against `kubectl get svc -n [namespace]`. Verify: host, port, and path agree.
3. If image pulls dominate, pre-pull with a DaemonSet or set `imagePullPolicy: IfNotPresent` with the image already cached. Verify: a subsequent start is fast.
4. Raise the client-side timeout to cover cold starts (kernel gateway `launch_timeout` / request timeout settings). Verify: slow but successful starts now complete.
5. If pods sit Pending, check quotas and requests: `kubectl describe pod [pod]`. Verify: the scheduler has room for the kernel pod.

## Variant phrasings
### kernel gateway timeout kubernetes
Short form. Events first, then the slow leg.

### jupyter enterprise gateway slow kernel start
The enterprise-gateway phrasing. Same pod-lifecycle causes.

### kernel provisioner timeout k8s
Provisioner-level phrasing. Pull and scheduling dominate.

Compatibility: jupyter kernel gateway / enterprise gateway 3.x, Kubernetes 1.25+. Timeout knobs live in gateway and client config.

## Why it happens
The gateway turns a kernel request into a pod lifecycle: schedule, pull image, start container, launch kernel, connect back. Any slow leg eats the client's timeout budget, and the client reports a generic timeout that hides which leg stalled.

## Edge cases / pitfalls
- Raising the timeout without fixing a Pending pod just waits longer for the same failure. Fix scheduling first.
- `imagePullPolicy: Always` on a big image guarantees a slow start every time. Cache deliberately.
- The gateway's own resource limits can throttle it under concurrent starts. Size the gateway for your peak.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_UMMEv4FW4WlDTUA1yZHvoA