Is Procore down right now?

While you wait: the Procore incident checklist

1. Name the dependency precisely. Procore is your work-management dependency. Identify which of these surfaces is actually in the production path: issue creation, project updates, automations, webhooks and incident handoffs.
2. Confirm the affected path. Use Procore's component and incident detail, then test API writes separately from the web interface and confirm whether automation or notification delivery is the failing component.
3. Bound every retry. Cap concurrency, use exponential backoff and retain idempotency where applicable. An upstream incident should not become a retry storm against Procore or your own services.
4. Use the rehearsed fallback. For this dependency, capture incident decisions in a durable fallback document and avoid duplicate ticket creation during retries. Do not invent a new failover path during the outage.
5. Verify recovery end to end. A green Procore status is the start of validation: backfill only the missing updates and reconcile automation that may execute after service returns.

What breaks when Procore has issues

Procore sits in the tickets & support layer. An incident can affect issue creation, project updates, automations, webhooks and incident handoffs; the exact blast radius depends on the components, regions and features your production path uses. Treat the official component timeline as evidence, compare it with your own independent probes, and communicate the user-visible effect rather than saying the whole vendor is simply “down.”