Status page and during-incident playbook

This page explains where to watch for platform-wide incidents and maintenance, how CoreWeave posts them, and what to do, and not do, while CoreWeave investigates. Use it when you suspect a platform issue rather than a problem in your own workload. For your own resource alerts, see CoreWeave Alerts.

​

Where to watch for incidents

CoreWeave publishes platform status, incidents, and planned maintenance at https://status.coreweave.com. The status page reports operational state for CoreWeave services and infrastructure, and it lists upcoming and in-progress maintenance windows. It’s your responsibility to subscribe to the status notifications relevant to your deployments. CoreWeave uses the status page as the primary channel for planned maintenance, and for critical maintenance it also emails subscribed users. For the formal commitment, see the Maintenance Policy.

​

Subscribe to updates

Subscribe on status.coreweave.com so you find out about incidents and maintenance without polling the page. The status page supports several subscription channels:

• Email: receive status updates in your inbox.
• RSS feed: pull updates into a reader or automation.
• Webhook: receive a JSON payload at an HTTPS endpoint you control.
• Slack: connect a Slack workspace.
• Microsoft Teams: deliver updates through an incoming webhook.

Subscribe with the channel that fits your operational workflow. For critical maintenance, also make sure the right people in your organization are subscribed to status email alerts, because that’s the channel CoreWeave uses for critical-maintenance notice. If you rely only on visually checking the dashboard, you can miss a notice, so subscribe by email so notices are pushed to you. When you subscribe, a few practices keep notices reliable:

• Subscribe a shared distribution list or alias rather than a single person, so notices are not missed when an individual is away.
• Subscribe only the components and Regions that match your deployments. This reduces noise while keeping the notices that matter.
• Add the status page sender to your mail allowlist so notices are not filtered as spam.
• Confirm the subscribed address received the confirmation message, so you know the subscription is active.

​

Status page versus CoreWeave Alerts

These two surfaces answer different questions. Knowing which to check saves time during an incident. If many of your workloads degrade at once and nothing changed on your side, check the status page first. If a single Node Pool, Pod, or job is unhealthy, start with CoreWeave Alerts and the Support articles for your product.

​

How CoreWeave posts incidents

When CoreWeave identifies a platform issue, it posts an incident on the status page and updates it as the investigation progresses. Planned maintenance is posted ahead of time with the affected services, the window, and the expected impact. Critical maintenance carries at least 24 hours’ notice by status page and email. Unplanned maintenance can happen at any time without notice when an outage or security issue puts the platform or customer data at risk. The Maintenance Policy is the authoritative source for these notice commitments and the components that count as critical.

​

During a maintenance window

When CoreWeave performs Node-level maintenance, CKS cordons, drains, and reboots Nodes in batches as needed. Draining honors your interruption labels, so a correctly labeled stateless workload drains cleanly and a non-interruptible job can defer eligible actions until it finishes. Because Nodes are processed in batches rather than all at once, capacity decreases gradually during the window rather than dropping all at once. Spreading critical replicas across Nodes reduces the chance that a single batch takes down a whole service. During the window, CoreWeave may temporarily suppress some automated Node health checks so that expected maintenance activity doesn’t trigger automated remediation. While that suppression is active, a Node may not show its usual health signals. This is expected during a window and clears when CoreWeave completes the work. A cordoned or rebooting Node inside a maintenance window is expected behavior, not a fault you need to fix. To reason about the blast radius of a notice before you act, match the components named in the maintenance notice to the workloads that depend on them: Node-level maintenance is the most common kind you encounter directly. To set workloads up to tolerate it, label them with the right interruption labels and checkpoint long-running jobs so a reboot costs minimal progress.

​

Verify recovery after a window

After a window completes, confirm your cluster returned to a healthy state:

1. Confirm each Node Pool recovered its target Node count and that no Nodes remain cordoned unexpectedly:
   # Compare target versus current Nodes for each Node Pool. Read-only.
   kubectl get nodepool
   
   # List any cordoned Nodes. Read-only.
   kubectl get nodes -o custom-columns='NODE:.metadata.name,UNSCHEDULABLE:.spec.unschedulable' \
     | grep true
   
2. Allow time for CoreWeave to re-enable health automation and re-run checks before you assume a Node is fully ready. A Node can appear schedulable a short time before its health checks complete.
3. If a Node remains cordoned well after the window ends, diagnose it. See Node cordoning.
4. Confirm your workloads rescheduled and are running. For Pods stuck Pending, check Node Pool status.

​

What to do during an incident

When you suspect a platform incident, work through these steps in order.

1. Confirm it’s platform-wide. Open status.coreweave.com and check whether an incident or maintenance window covers the affected service, Region, or Availability Zone. Read the latest update on the incident.
2. Scope the impact on your side. Determine which clusters, Node Pools, or workloads are affected and whether it matches the posted incident. Check CoreWeave Alerts and your dashboards.
3. If an incident is already posted, follow its updates. CoreWeave is already engaged, and the status page is the fastest source of progress. You generally don’t need to open a ticket for an already-posted incident unless you have impact details CoreWeave would not otherwise know.
4. If no incident is posted but you see broad impact, open a support ticket with evidence. See when to open a ticket.
5. Avoid disruptive remediation. See what not to do.

​

What not to do while CoreWeave investigates

During an active incident, some instinctive reactions make recovery harder or risk data:

• Don’t mass-delete or recreate clusters, Node Pools, or PersistentVolumeClaims in response to an unconfirmed platform issue. Deleting a PVC can be destructive. See Recover a deleted PVC before acting.
• Don’t patch or modify CoreWeave-managed resources to work around an incident. For the boundary, see What CoreWeave manages.
• Don’t open many duplicate tickets for the same issue. One ticket with good evidence is more useful than several thin ones.
• Don’t assume the issue is platform-wide before checking the status page and your own scoping. Many issues that feel platform-wide are workload-specific.

​

When to open a ticket versus wait

Use this guidance to decide:

• Wait and watch when an incident covering your symptom is already posted on the status page. CoreWeave is engaged, and updates flow to the channel you subscribed to.
• Open a ticket when no incident is posted and you have broad, unexplained impact, when your impact differs from what a posted incident describes, or when you have evidence that would help CoreWeave scope the problem. Always open a ticket for issues isolated to your workload or account.

When you open a ticket, include the affected organization, namespace, Region or Zone, timestamps, and the specific symptoms. For what to include, see Contact support and Ticket templates.

​

Related pages

• Maintenance Policy: CoreWeave’s formal maintenance and notification commitments.
• CoreWeave Alerts: notifications about your own resources.
• Support articles: browse help by product and symptom.
• Contact support: how to open a ticket.