Coinbase today issued a statement regarding an incident affecting its services on July 14, 2026.

The affected services include transfers, card transactions, and onchain services across Coinbase’s retail, institutional, and developer platforms. This degraded state lasted approximately 50 minutes, with residual delays as queued transactions processed afterward. This was caused by an unintended misconfiguration of an important network component as a result of a routine configuration update.

Coinbase notes that customer funds were not at risk.

The company stated the following:

• “What happened?

At 12:34 PM ET, a routine configuration change was deployed to a shared production Kubernetes cluster that hosts core infrastructure services. The configuration change was part of an ongoing migration to a new service deployment model to improve system performance and reliability; it was reviewed and deployed through our standard pipeline as a low-risk change.

One architecture component of this cluster is the Istio ingress gateway, which regulates network traffic entering the cluster destined for infrastructure services. The configuration change inadvertently modified Kubernetes resources associated with this gateway due to a collision in resource names that was not detected by our pre-production checks, resulting in unavailability of the gateway. By 12:37 PM ET, all inbound traffic to the cluster stopped, cutting off internal clients from accessing several infrastructure services.

This loss of network access impacted nearly all internal asynchronous workflows. Workflows are how Coinbase moves money: trades settle, transfers complete, and card transactions are authorized through them. When infrastructure services became unreachable, those workflows paused platform-wide.

• What our customers experienced

Between 12:37 PM ET and approximately 1:25 PM ET:

Retail customers were unable to complete off-platform trades/deposit/withdrawals. In-flight transactions appeared stuck rather than failed, and completed once service was restored.

Coinbase Card debit transactions were declined for the duration of the incident. Credit card purchases continued to work, but card management features were unavailable.

Onchain swaps through Coinbase DEX on Base and Solana were unavailable.

Coinbase Exchange and Prime customers experienced failed or delayed transfers and settlement activity.

Coinbase Developer Platform customers were unable to onboard, move funds, or use onramp services.

We halted affected flows and posted status updates across our Retail, Exchange, and Prime status pages while recovery was underway. Gateway service was restored at 1:20 PM ET and the incident was mitigated at 1:23 PM ET. Queued workflows then completed, with most services fully caught up shortly after and remaining backlogs completing over the following hours.

• Recovery

The direct fix was conceptually simple: redeploy the ingress gateway to the latest stable version. Two issues made it harder in practice.

First, a circular dependency. Engineers’ network access to our deployment tooling depends on the impacted ingress gateway being available. When the gateway went down, so did our ability to roll back the change through standard operating procedures. The tool we would normally use to fix the problem was itself impacted.

Second, checks in our break-glass path are intentionally frictionful and can be streamlined. Engineers recovered the gateway by manually invoking a rollback deployment workflow in our cloud provider, using just-in-time privileged access. That path worked, but permission checks and procedural scrutiny added time and can be streamlined to move more quickly.

• What we are doing about it

As a part of our continued investment in reliability, we are taking immediate action to prevent a similar incident from occurring in the future:

We are extending our deploy-time guardrails to detect and block Kubernetes resource name collisions, so a deployment cannot inadvertently modify resources from neighboring components and are stress testing these guardrails to ensure they’re inclusive of other plausible issues.

We are improving redundancy between our deployment tooling and the infrastructure it manages, so the tools we need in an outage cannot be taken down by the outage itself.

We are auditing and regularly exercising our break-glass access paths, so the manual recovery route is fast and reliable when we need it.

• Closing

Our goal is always zero downtime. We are actively redesigning our infrastructure to ensure that, in the highly unlikely event of another failure like this one, we can swiftly revert and recover. We regret the disruption experienced by our users and apologize for any inconvenience this may have caused. “