🎉 DevOps Interview Prep Bundle is live — 1000+ Q&A across 20 topicsGet it →
All Fixes
Today I Fixed

kubectl port-forward keeps disconnecting after 60 seconds

kubectlMay 26, 202625 minutes to fixkubernetestroubleshooting

kubectl port-forward connected successfully, then exited after roughly one minute. The application was still running, so restarting the command appeared to fix it only temporarily.

What I checked first

Run the command with client-side debug logging and keep a second terminal open:

bash
kubectl -v=6 port-forward pod/my-pod 8080:8080
bash
kubectl get pod my-pod -w
kubectl describe pod my-pod

This separates two common cases:

  • If the selected pod restarts or terminates, the forwarding session is expected to end. Kubernetes documents that the command must be run again after the selected pod terminates.
  • If the pod remains stable and the disconnect happens at a repeatable interval, inspect the network path to the Kubernetes API server. A VPN, corporate proxy, bastion, firewall, or managed load balancer can close a long-lived idle connection.

Do not copy examples that use kubectl port-forward --keepalive=60s. --keepalive is not a documented kubectl port-forward option.

The practical fix

The durable fix is to correct the component that is closing the connection. Compare the failing path with a direct or alternate path to the API server, where your access policy allows it:

bash
kubectl config current-context
kubectl cluster-info

Then test after disconnecting the VPN or bypassing the proxy only if doing so is approved in your environment. If the alternate path stays connected, give the network team the exact interval and the -v=6 timestamps so they can inspect idle timeout settings.

For a local development session, I used a restart loop as a temporary workaround:

bash
while true; do
  kubectl port-forward pod/my-pod 8080:8080
  echo "port-forward ended; retrying in 2 seconds" >&2
  sleep 2
done

This restores the tunnel after a disconnect, but it does not repair the underlying network timeout. It also should not be used as a production service.

If the pod itself is restarting

Forward to a controller instead of a specific pod when that better matches the use case:

bash
kubectl port-forward deployment/my-app 8080:8080

Kubectl selects a matching pod, but the current session still ends if that selected pod terminates. The loop can reconnect and select a new pod, while the real task is to diagnose the restart:

bash
kubectl get pods -l app=my-app
kubectl logs pod/my-pod --previous
kubectl describe pod my-pod

Safety note

The default listener is localhost. Avoid --address 0.0.0.0 unless you intentionally want other machines to reach the forwarded port and have appropriate firewall and authentication controls.

For a wider Kubernetes debugging workflow, see the Kubernetes troubleshooting guide. If the API server itself is unreachable, use the kubectl connection refused checklist.

Sources

Did this fix work?

Tell us what needs improving. No account required.