## TL;DR
There are no logs because the pod never started: Pending means the Kubernetes scheduler could not place it. The agent should read the pod events for the placement reason instead of waiting for logs that will never exist. Report the placement block, do not keep polling an empty log stream.

```text
agent timed out waiting for kubernetes pod logs, pod stuck pending
```

## Use this when
- An agent waits for pod logs but the pod stays Pending.
- The log stream is empty and stays empty.
- The agent's timeout fires on the log wait.

## Not for this skill when
- The pod runs and logs exist. Read them.
- The pod fails after starting. Debug the container.

## Steps
1. Stop waiting for logs and describe the pod, reading the events section. Note the placement reason. Verify: the real signal is found
2. Classify the block: Unschedulable (resources), ImagePullBackOff (image), or selector mismatch. Note the class. Verify: the block is categorized
3. Report the placement block with the event text instead of reporting missing logs. Note the report. Verify: the escalation names the cause
4. If the agent can act, address the block: adjust requests, fix the image reference, or wait for capacity. Note the action. Verify: the block is addressed or escalated
5. Only resume log-waiting after the pod reaches Running. Note the state gate. Verify: waiting resumes only when logs can exist

## Variant phrasings
### kubernetes pod pending no logs
The symptom phrasing.
### agent wait pod logs pending
The agent-shaped search.

Compatibility: Kubernetes pod events via kubectl describe or the API. Placement reasons are cluster-independent.

## Why it happens
Logs are a property of running containers; a Pending pod has no containers yet, so the log stream is empty by definition. Agents that poll for logs are asking the wrong question: the question is why the scheduler has not placed the pod, and the answer is in the pod events. This is a small instance of a general agent skill: when the expected artifact cannot exist, stop waiting for it and investigate the precondition.

## Edge cases / pitfalls
- Init containers can also hold a pod in Pending-adjacent states. Check init container status too.
- Log aggregation systems may show the pod as missing rather than pending. Check the orchestrator state, not just the log store.
- A pod that flaps between Pending and Running produces partial logs. Gate log collection on sustained Running.
- Tolerations and node affinity issues are invisible in logs. The events section is the only witness.

## Provenance

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