> ## Documentation Index > Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt > Use this file to discover all available pages before exploring further. # Support ticket templates > Per-domain checklists of the evidence to include so your first support message has what the team needs A support ticket resolves faster when the first message includes the evidence the team needs to diagnose the problem. This page lists per-domain templates: what to describe, what commands to run, and what output to attach. Copy the relevant template into your ticket and complete it before you submit. For how to reach support, see [Contact support](/support/contact). To decide whether the problem is yours or CoreWeave's before you file, see [what CoreWeave manages](/support/what-coreweave-manages). ## What every ticket needs Include this for every ticket, regardless of domain: * Your organization name and the namespace where the issue occurs. * The cluster name and the Region or Availability Zone, if relevant. * A one-line summary of the symptom, then the exact error string you see. * When it started, and whether it is constant or intermittent. * What changed recently, for example a deploy, a config change, or a scale-up. * The priority: Low, Medium, High, or Urgent. Share manifests and configuration as text or attachments. Redact secrets before sharing. Never paste credentials, tokens, or private keys into a ticket. For how to do this, see [Share evidence safely](#share-evidence-safely). State the symptom first, then the evidence, then what you've already concluded. Support engineers triage by symptom, so a ticket that opens with the exact error string and the affected resource name is routed and resolved faster than one that opens with a narrative. A good first message looks like: ```text title="Example ticket body" theme={"system"} Org: example-org Namespace: training Region: US-EAST-04 Symptom: Pods stuck Pending since 2026-06-26 14:10 UTC, ongoing. Error: "0/12 nodes are available: 12 Insufficient nvidia.com/gpu." Scope: deployment training-run-7, 4 replicas, all Pending. Tried: confirmed Node Pool CURRENT=TARGET, GPUs appear allocated to other Pods. Attached: kubectl describe pod output, kubectl get nodepool output. Priority: High. ``` ## Diagnose before you file Run the following read-only commands first. Often they pinpoint the cause so you can fix it without a ticket. When they don't, their output is exactly the evidence to attach. Replace any `[PLACEHOLDER]` with your own value. For a Pending Pod, read its events and confirm Node Pool capacity: ```bash theme={"system"} # Show why a Pod is unscheduled. Read-only; safe to run anytime. kubectl describe pod -n [NAMESPACE] [POD-NAME] # Show capacity, quota, and Node counts for a Node Pool. Read-only. kubectl get nodepool [NODEPOOL-NAME] ``` How to read the output: in the Pod's `Events`, a line like `0/12 nodes are available: 12 Insufficient nvidia.com/gpu` means no Node has a free GPU, `node(s) had untolerated taint(s)` means a taint is blocking the Pod, and `didn't match Pod's node affinity/selector` means your `nodeSelector` matches no Node. On the Node Pool, `CURRENT` should equal `TARGET`. A `QueuedAwaitingCapacity` state means CoreWeave is waiting on capacity, and an over-quota state means you are at your ceiling. See [Node Pool status](/products/cks/nodes/nodepool-status). For a Node's health and cordon status: ```bash theme={"system"} # Show a Node's conditions, taints, and schedulability. Read-only. kubectl describe node [NODE-NAME] # Read the CoreWeave cordon reason for a Node. Read-only. kubectl get node [NODE-NAME] -o jsonpath='{.metadata.annotations.node\.coreweave\.cloud/cordonReason}' ``` How to read the output: `Unschedulable: true` means the Node is cordoned. A CoreWeave cordon reason such as `NLCCPendingExitProduction` is an expected planned lifecycle action, while `NeedsTriage` is a health signal. An empty result means a plain `kubectl cordon` likely set it. See [Node cordoning](/products/cks/nodes/cordon). For a crashing or restarting Pod: ```bash theme={"system"} # Show the logs from the previous (crashed) container instance. Read-only. kubectl logs -n [NAMESPACE] [POD-NAME] --previous ``` How to read the output: `--previous` returns the logs from the instance that just crashed, which usually contains the actual error. For an `OOMKilled` Pod, the container exceeded its memory limit, so raise the limit or reduce memory use. For a storage mount problem, confirm the volume is bound and has space: ```bash theme={"system"} # Show the bound PVC, its storage class, and capacity. Read-only. kubectl describe pvc -n [NAMESPACE] [PVC-NAME] # Inside a running Pod, list mounts and free space. Read-only. kubectl exec -n [NAMESPACE] [POD-NAME] -- df -h ``` How to read the output: `Status: Bound` means the volume is attached to the claim. In `df -h`, `Use%` near `100%` causes `ENOSPC` errors, and a missing mount path means the volume isn't mounted where the workload expects. For CoreWeave AI Object Storage access, confirm credentials and endpoint: ```bash theme={"system"} # List buckets to confirm credentials and endpoint work. Read-only. # Replace [ENDPOINT-URL] with your AI Object Storage endpoint. aws s3 ls --endpoint-url [ENDPOINT-URL] ``` How to read the output: a list of buckets means your credentials and endpoint are correct. `AccessDenied` means the credentials lack permission or a policy blocks them, and a connection error means the endpoint URL is wrong or unreachable. ## CKS tickets For CKS scheduling, Node, and cluster problems, include the following: * The Pod or workload manifest, with secrets redacted. * The output of describing the failing Pod: ```bash theme={"system"} kubectl describe pod [POD-NAME] -n [NAMESPACE] ``` * Recent events in the namespace: ```bash theme={"system"} kubectl get events -n [NAMESPACE] --sort-by=.lastTimestamp ``` * For scheduling or capacity problems, the Node Pool status: ```bash theme={"system"} kubectl get nodepool [NODEPOOL-NAME] -o yaml ``` * For a Node problem, the Node description, with conditions and taints: ```bash theme={"system"} kubectl describe node [NODE-NAME] ``` To interpret the output before you file, see [Node Pool status](/products/cks/nodes/nodepool-status) and [Node cordoning](/products/cks/nodes/cordon). ## SUNK tickets For Slurm job and Node problems on SUNK, include the following: * The job submission command or the batch script, with secrets redacted. * The job ID and the reason shown in the queue: ```bash theme={"system"} squeue -j [JOB-ID] -o "%i %T %r" ``` * The detailed job record for a failed or stuck job: ```bash theme={"system"} scontrol show job [JOB-ID] ``` * The state of the Nodes the job targeted: ```bash theme={"system"} sinfo -N -o "%N %T %E" ``` * For a drained or down Node, the reason string from `sinfo` or `scontrol show node`. To interpret the state and reason fields, see [Monitor Slurm node states](/products/sunk/manage_sunk/slurm-node-states) and [Stuck Slurm nodes](/products/sunk/manage_sunk/stuck-slurm-nodes). ## Storage tickets For file storage, PVC, and object storage problems, include the following: * The storage product involved: Distributed File Storage, a PVC, AI Object Storage, or Local Storage. * The exact error string from the client or the mount. * For a PVC or mount problem, the PVC and Pod state: ```bash theme={"system"} kubectl get pvc -n [NAMESPACE] kubectl describe pod [POD-NAME] -n [NAMESPACE] ``` * For an object storage problem, the failing client command with the bucket name, the endpoint, and the addressing style. Redact access keys. * A timestamp for when the failed request occurred, so the team can correlate it. For the relevant context, see [Recover a deleted PVC](/products/storage/distributed-file-storage/recover-deleted-pvc) and [Configure endpoints](/products/storage/object-storage/using-object-storage/configure-endpoints). ## Networking tickets For connectivity, DNS, and LoadBalancer problems, include the following: * The source and destination: Pod to Pod, Pod to Service, Pod to external host, or external to LoadBalancer. * The exact error string, for example `connection refused`, `i/o timeout`, or a DNS failure. * The Service and any network policy involved: ```bash theme={"system"} kubectl get svc [SERVICE-NAME] -n [NAMESPACE] -o yaml kubectl get endpoints [SERVICE-NAME] -n [NAMESPACE] ``` * A reproduction from inside a Pod, for example a `curl` or a DNS lookup against the target, with the full output. * For an external connectivity problem, the public IP or DNS name involved and the direction of the traffic. For context on routing and address overlaps, see [About networking](/products/networking) and [VPC CIDR blocks](/products/networking/vpc/vpc-cidr). ## Training tickets For distributed training problems such as NCCL failures, GPU errors, or slow throughput, include the following: * The instance type, the number of Nodes and GPUs, and the framework and version. * The exact error string, for example a NCCL error code, an XID number, or a collective timeout message. * The per-rank logs around the first failure, not just rank 0. The first rank to fail usually identifies the cause. * For a suspected GPU fault, the XID messages from `dmesg` and the Node name. * For a performance problem, the observed throughput and the baseline you expected, so the team can quantify the gap. * For a job that uses the high-performance fabric, confirmation that RDMA is requested and active in the Pod. For the networking context, see [Use GPUDirect RDMA](/products/networking/hpc-interconnect/use-gpudirect-rdma) and [InfiniBand and RoCE labels](/products/networking/hpc-interconnect/infiniband-roce-labels). For how CoreWeave handles a faulty GPU, see [Node cordoning](/products/cks/nodes/cordon). ## Share evidence safely Sharing the right evidence safely is as important as sharing it at all. Support doesn't need your credentials to help. * **Never share live credentials.** A kubeconfig that contains a token, client certificate, or client key is a credential. Share the cluster name and Region instead of the kubeconfig. * **Redact secrets from manifests and `-o yaml` output.** Before attaching, scan the output for any `data:` block under a `Secret`, any `token`, `password`, `key`, or `certificate` field, and any environment variable that holds a credential. Replace each value with `[REDACTED]`. * **Strip credentials from scripts and command history.** Remove access keys, secret keys, and bearer tokens from `sbatch` scripts, `aws` commands, and shell history before attaching them. Capture logs scoped to the affected resource and time window, not entire cluster dumps: ```bash theme={"system"} # Capture recent logs for a specific Pod, scoped to the problem. Read-only. # --since limits the window; --previous gets a crashed container's logs. kubectl logs -n [NAMESPACE] [POD-NAME] --since=1h kubectl logs -n [NAMESPACE] [POD-NAME] --previous ``` Before sharing, confirm the log window covers the failure and remove any line that prints a token, key, or customer-identifying value. ## After you submit Keep the ticket focused: one problem per ticket. If you discover new evidence, add it to the existing ticket rather than opening a new one. If the problem is urgent and affects production, set the priority accordingly and include the impact. For the full contact options, see [Contact support](/support/contact).