Support ticket templates - CoreWeave Docs

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. To decide whether the problem is yours or CoreWeave’s before you file, see 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. 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:

Example ticket body

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:

# 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. For a Node’s health and cordon status:

# 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. For a crashing or restarting Pod:

# 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:

# 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:

# 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:

kubectl describe pod [POD-NAME] -n [NAMESPACE]

Recent events in the namespace:

kubectl get events -n [NAMESPACE] --sort-by=.lastTimestamp

For scheduling or capacity problems, the Node Pool status:
kubectl get nodepool [NODEPOOL-NAME] -o yaml
For a Node problem, the Node description, with conditions and taints:
kubectl describe node [NODE-NAME]

To interpret the output before you file, see Node Pool status and Node cordoning.

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:
squeue -j [JOB-ID] -o "%i %T %r"
The detailed job record for a failed or stuck job:
scontrol show job [JOB-ID]
The state of the Nodes the job targeted:
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 and 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:

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 and 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:

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 and VPC CIDR blocks.

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 and InfiniBand and RoCE labels. For how CoreWeave handles a faulty GPU, see Node cordoning. 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:

# 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.

​What every ticket needs

​Diagnose before you file

​CKS tickets

​SUNK tickets

​Storage tickets

​Networking tickets

​Training tickets

​Share evidence safely

​After you submit