Reown Outage History

Started Dec 16, 2025, 02:43 PM UTC· resolved Dec 17, 2025, 01:39 PM UTC

1. identified Dec 16, 2025, 02:43 PM UTC

   The issue has been identified and a fix is being implemented.

2. resolved Dec 17, 2025, 01:39 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Dec 16, 2025, 10:22 AM UTC· resolved Dec 16, 2025, 02:41 PM UTC

1. identified Dec 16, 2025, 10:22 AM UTC

   The issue has been identified and a fix is being implemented.

2. resolved Dec 16, 2025, 02:41 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Dec 05, 2025, 09:05 AM UTC· resolved Dec 05, 2025, 09:28 AM UTC

1. investigating Dec 05, 2025, 09:05 AM UTC

   One of our upstream providers is experiencing an apparent wide spread outage and returning 500 errors across our services and others. For more information, please see: https://www.cloudflarestatus.com/incidents/lfrm31y6sw9q

2. monitoring Dec 05, 2025, 09:15 AM UTC

   A fix has been implemented and we are monitoring the results.

3. resolved Dec 05, 2025, 09:28 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Nov 18, 2025, 01:24 PM UTC· resolved Nov 18, 2025, 04:11 PM UTC

1. investigating Nov 18, 2025, 01:24 PM UTC

   Users unable to login via email or sign messages due to upstream provider (Magic Link) outage. Magic team is currently investigating.

2. investigating Nov 18, 2025, 01:24 PM UTC

   We are continuing to investigate this issue.

3. investigating Nov 18, 2025, 02:23 PM UTC

   Traffic to walletconnect.org and walletconnect.network zones is also impacted due to upstream provider issues at Cloudflare. See: https://www.cloudflarestatus.com/incidents/8gmgl950y3h7

4. monitoring Nov 18, 2025, 03:11 PM UTC

   A fix has been implemented and we are monitoring the results.

5. monitoring Nov 18, 2025, 03:17 PM UTC

   We are continuing to monitor for any further issues.

6. resolved Nov 18, 2025, 04:11 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Oct 21, 2025, 05:52 PM UTC· resolved Oct 21, 2025, 08:23 PM UTC

1. investigating Oct 21, 2025, 05:52 PM UTC

   We are currently investigating this issue.

2. resolved Oct 21, 2025, 08:23 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Sep 26, 2025, 10:12 AM UTC· resolved Sep 26, 2025, 07:27 PM UTC

1. investigating Sep 26, 2025, 10:12 AM UTC

   We are investigating an issue with Coinbase deposits in payments and Deposit from exchange flows.

2. resolved Sep 26, 2025, 07:27 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Sep 05, 2025, 08:32 AM UTC· resolved Sep 05, 2025, 09:36 PM UTC

1. investigating Sep 05, 2025, 08:32 AM UTC

   Since August 27, we have observed intermittent spikes in 500 errors affecting api.web3modal.org and explorer-api.walletconnect.org. The underlying issue is related to our database, which is experiencing sudden surges in client connections. Our engineering team is actively investigating and continuing root cause analysis to mitigate the impact. Users may experience intermittent failures when interacting with the Explorer API and Web3Modal API during these periods. We will provide updates as we learn more.

2. resolved Sep 05, 2025, 09:36 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jul 08, 2025, 07:39 AM UTC· resolved Jul 08, 2025, 12:25 PM UTC

1. investigating Jul 08, 2025, 07:39 AM UTC

   We are currently investigating this issue.

2. monitoring Jul 08, 2025, 11:44 AM UTC

   A fix has been implemented and we are monitoring the results.

3. resolved Jul 08, 2025, 12:25 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 12, 2025, 02:30 AM UTC· resolved Jun 12, 2025, 09:25 PM UTC

1. investigating Jun 12, 2025, 06:45 PM UTC

   An upstream incident is causing partial or full outages. Follow https://www.cloudflarestatus.com/

2. monitoring Jun 12, 2025, 08:57 PM UTC

   A fix has been implemented and we are monitoring the results.

3. resolved Jun 12, 2025, 09:25 PM UTC

   This incident has been resolved.

Read the full incident report →

Started May 28, 2025, 01:50 PM UTC· resolved May 28, 2025, 02:54 PM UTC

1. investigating May 28, 2025, 02:29 PM UTC

   Relay deployments in sa-east-1 are partially unavailable. The team is currently investigating the issue.

2. investigating May 28, 2025, 02:42 PM UTC

   Availability issues subsided. We are continuing to investigate this issue.

3. resolved May 28, 2025, 02:54 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Feb 28, 2025, 06:46 PM UTC· resolved Feb 28, 2025, 07:05 PM UTC

1. identified Feb 28, 2025, 06:46 PM UTC

   AppKit Social Login is currently Unavailable. We've identified the issue and will provide updates here.

2. identified Feb 28, 2025, 06:46 PM UTC

   We are continuing to work on a fix for this issue.

3. resolved Feb 28, 2025, 07:05 PM UTC

   This incident is resolved

Read the full incident report →

Started Feb 22, 2025, 11:56 AM UTC· resolved Feb 22, 2025, 03:13 PM UTC

1. investigating Feb 22, 2025, 11:56 AM UTC

   We are investigating an upstream issue with our database provider. Requests to explorer-api.walletconnect.org are failing, and all wallets aren't showing up on WalletConnect Modal as a result of that.

2. resolved Feb 22, 2025, 03:13 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Feb 12, 2025, 08:54 AM UTC· resolved Feb 16, 2025, 04:47 PM UTC

1. identified Feb 12, 2025, 08:54 AM UTC

   Magic Link is experiencing degraded performance on Login and Signing. The Magic team has identified the issue and is working on a fix.

2. monitoring Feb 14, 2025, 08:22 AM UTC

   A fix has been implemented by Magic team and we are monitoring the results.

3. resolved Feb 16, 2025, 04:47 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jan 21, 2025, 09:03 AM UTC· resolved Jan 21, 2025, 09:07 AM UTC

1. identified Jan 21, 2025, 09:03 AM UTC

   The issue has been identified and a fix is being implemented.

2. resolved Jan 21, 2025, 09:07 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Jan 06, 2025, 11:30 PM UTC· resolved Jan 06, 2025, 11:30 PM UTC

1. resolved Jan 07, 2025, 03:41 PM UTC

   We experienced an hour-long outage on walletguide.walletconnect.network due to requests to an upstream API timing out. The root cause is still under investigation and the application is operational again. Other services are healthy and were not affected by this issue.

Read the full incident report →

Started Dec 20, 2024, 08:08 PM UTC· resolved Dec 21, 2024, 11:41 PM UTC

1. investigating Dec 20, 2024, 08:08 PM UTC

   We are currently investigating an issue with DNS resolution of the walletconnect.network domain and related subdomains such as airdrop.walletconnect.network.

2. investigating Dec 20, 2024, 09:38 PM UTC

   We are continuing to investigate this issue.

3. investigating Dec 20, 2024, 11:04 PM UTC

   We have escalated the issue to the Cloudflare Registrar team and are exploring avenues to bring affected services back online.

4. identified Dec 21, 2024, 10:12 PM UTC

   The issue has been identified and we are in contact with relevant parties to resolve the issue as quickly as possible.

5. monitoring Dec 21, 2024, 11:15 PM UTC

   A fix has been implemented and we are monitoring the restoration of all walletconnect.network services.

6. resolved Dec 21, 2024, 11:41 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Dec 16, 2024, 05:13 PM UTC· resolved Dec 16, 2024, 06:34 PM UTC

1. investigating Dec 16, 2024, 05:13 PM UTC

   We are currently investigating this issue.

2. identified Dec 16, 2024, 06:16 PM UTC

   The issue has been identified and a fix is being implemented.

3. resolved Dec 16, 2024, 06:34 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Dec 04, 2024, 07:45 PM UTC· resolved Dec 04, 2024, 08:50 PM UTC

1. monitoring Dec 04, 2024, 07:45 PM UTC

   Arbitrum on Blockchain API is unavailable because of a downstream provider being down. We are deploying a fic.

2. resolved Dec 04, 2024, 08:50 PM UTC

   This incident has been resolved.

3. postmortem Dec 09, 2024, 04:06 AM UTC

   ### **TL;DR** In the December 4, 2024 evening ~7PM CET we got the AWS Canary alarm about the Blockchain-RPC Arbitrum chain unavailability. We started investigating the issue, since we have a few providers for each non-testnet chain and our load-balancing implementation should redirect the traffic to the available provider. We have two “paid” providers for the Arbitrum: Pokt/Grove and Infura, both of them were unavailable due to rate-limiting in Infura, and HTTP 503 errors in Pokt/Grove. We changed to redirect traffic to the one available free Publicnode provider, but because of the traffic amount we were rate-limited fast. We have another “paid” provider with a big amount of RPC calls included \(Quicknode\), but there was a limit to the used endpoints and we were used it for other chains. For the hotfix, we’ve decided to swap the less-used chain to the Arbitrum for the Quicknode provider. That hotfixed a chain RPC outage and redirected the traffic to the Quicknode provider. ### **Summary** * When did it start/end: * December 4, 2024 ~7PM CET - 9PM CET * Who found the issue? * We got our AWS Canary alert, @Max Kalashnikov started to investigate it and @Derek Rein connected to partners \(infura and Pokt\) for a resolution * Customers were also complaining in Discord and Telegram and @Tomas Rawski jumped into this as well. * How was it mitigated? * We swapped the less-used chain for the Arbitrum in the single-alive RPC provider. * What was the \(customer\) impact? * All RPC calls to the Arbitrum don’t work with `HTTP 503 Temporarily Unavailable` error. ### **Root Cause** 2 of 2 of our paid providers for Arbitrum were down and the amount of traffic was too big for free RPCs: * Infura - We had a pay-as-you go plan above 10mio calls per day - Infura switched the plan back to a fix limit without letting us know and we usually don’t hit the limit because we balance load across providers - only when Pokt went down and all load went to Infura were we affected * Pokt/Grove - Pokt was down for about 24h. We are in touch with their team but have not receive a proper root cause. They acknowledged that 50% of all calls to Pokt were failing ### **5 Whys** * Why was the service down for the Arbitrum chain? * We have experienced increasing in traffic for the Arbitrum and 2 of 2 our “paid” providers who can process such amount of requests were down. * Why we are using paid providers for the Arbitrum chain? * We have plenty amount of traffic that can be handled only by paid plans. * Why we are using Pokt and Infura for this? * Infura has a pay-as-you-go plan so we shouldn’t be rate-limited. * Pokt has a good RPC calls per $ ratio and can handle such an amount of traffic for less. * Why have these providers become unavailable? * Pokt had a rebranding recently this year and after we had issues almost every month with they RPC nodes, like node unavailable or flaky responses. We still use it for other chains because it’s cheap and has plenty of RPC calls. * Infura just forgot to reinstall our rate-limiting exception and it’s expired. * Why we don’t have more providers? * We have another paid provider - GetBlock, but limits are too low for us and we drain it after a few days of usage and then it’s dropped out because of rate-limiting. * We were thinking that two paid providers with high limits must be enough. ### **What could we have done better?** We should remove unstable providers \(Pokt\) and providers with low limits \(GetBlock\) to be sure that we are using at least two stable providers. ### How can we prevent this from happening again? * We should monitor better which providers are consistently flaky and remove them and remove providers that have too low limits for us. * We should find and add more stable RPC providers with high limits. ### **Action items** * \[ \] Find at least two new RPC providers with a pay-as-you-go plan and good RPC calls/$ ratio to use not just for an Arbitrum, but for all top traffic chains. * \[ \] Remove Pokt and GetBlock providers in favor of new ones. * \[ \] Add more free native RPC endpoints where available to distribute a load from paid providers a bit.

Read the full incident report →

Started Nov 26, 2024, 04:00 PM UTC· resolved Nov 26, 2024, 04:00 PM UTC

1. resolved Nov 29, 2024, 03:20 PM UTC

   We are currently investigating this issue.

2. postmortem Nov 29, 2024, 03:21 PM UTC

   ### Summary  Exhibit 1: AppKit API errors  Exhibit 2: Postgres/Supavisor Client Connections We experienced a full outage of the airdrop claim page from 1220am Singapore to ~430am Singapore. The claim page was opened and rolled back 3 times and most users trying to claim within the open periods were unable to do so. It caused delaying the announcement of the airdrop claim from ~1am Singapore to ~5am Singapore. The root cause was an underprovisioned database and a bug in the connection pooler of the database provider which was mitigated by migrating to a different connection pooling provider. The issue was uncovered by internal alarms going off first but also via complaints in Telegram and other sources.  Exhibit 3: Hyperdrive errors Thereafter we experienced a partial outage of the claim page where more than half of users got sporadic/intermittent `Internal server errors` when trying to log in. The partial outage lasted from ~5am Singapore to ~10am Singapore. Up to ~65% of queries were affected. The root cause was a misconfiguration of the connection pooling of the provider we migrated to as part of mitigating the full outage. The issue was first uncovered by internal metrics. A business decision was made to proceed with taking the claim live despite these errors. It was then reported by multiple customers via different channels. **Out of scope** * _Congrats claim 0 wct_ - **T**here was a bug showing eligible users who connected a different but the `recipient address` of their airdrop that they received 0 WCT. This was live until ~3pm Singapore and affected a of 1.5k users. It is out of scope of this COE which focusses on the database issues and learnings thereof. * Twitter scam list - how we ended up on the Twitter list and how to make sure it won’t happen again is out of scope * Disperse - we ran into some issues on dispersing the gas delaying the launch. That’s out of scipe here too ### **Root Cause**  Exhibit 3: registration traffic was lower than claim page traffic **Background** The AppKit API powering the claim page login/profile feature is hosted on a _Serverless_ Cloudflare worker. A best practice for database connections in such environments is to use server-side connection pooling. We used a connection pooler provided by Supabase called _Supavisor_ for this. **Full outage** The traffic to the claim page exceeded the provisioned max connections for Supavisor - see exhibit 2. We didn’t expect this to happen as we didn’t expect more traffic than during the registration phase. The connection spike also caused the CPU to spike. Vertical scaling increases the provisioned max connections. We vertically scaled twice and took the site online again causing the database to exceed connections. This is because we ran into an issue with Supavisor where despite vertical scaling the max connections didn’t increase. This is a bug in Supavisor we reported. We changed the connection pooling method when taking the site online a third time. This, as expected, exceeded the pool size quickly. Building the hypothesis was difficult as we didn’t expect the Supavisor software to be broken. The issue was mitigated by moving to Cloudflare _Hyperdrive_ an alternate connection pooler. This required updating code and provisioning Hyperdrive which took a long time.  Exhitbit 4: `58000` Postgres errors **Partial Outage** After confirming that connection pooling was no longer an issue on Hyperdrive we still had elevated amounts of HTTP5XX errors. CloudWatch errors showed a large amount `58000` error which we first analyzed as database internal errors. Later we found that the pool size on the database was too low. The pool size was `25` but we need at least `100` for Hyperdrive at peak traffic levels. The partial outage was mitigated by increasing the pool size to `128` and later to `192`. We announced the claim despite knowing there was a partial outage and took it as a business risk. ### **5 Whys** _Why was the claim page down?_ Because we exceeded the max provisioned connections. _Why did you exceed the max provisioned connections?_ We did not expect more traffic than during the registration page where this setup was resilient. _Why did provisioning more connections not immediately fix the issue?_ A bug Supavisor caused the actual provisioned connections to not increase. _Why did you not switch to Hyperdrive sooner?_ It was difficult/risky to build/validate the hypothesis that Supavisor’s core functionality is broken. _Why did you not configure Hyperdrive correctly from the start?_ We didn’t research enough about the impact of the pool size on the spot. And the error messages on Cloudflare hinted at other issues when we researched. ### **What went well?** * tons of folks helping and on the incident call * internal metrics which we invested in heavily were great and better than what Supabase provides themselves * Our systems fired alarms immediately ### **What could we have done better?** * We could have configured a bigger instance from the start * We could have done more research on the pool size ahead of time * The third iteration of taking the site online was redundant and had little chances of success * We could have just prophylactically increased the pool size to see what happens as an experiment * We could have analyzed more data in a related COE during registrations * Airdrop was late and the launch was at midnight for the main operator of the claim site who also suffered from food poisoning that day - we could’ve targeted a launch earlier in the day ### How can we prevent this from happening again? * We understand now how many concurrent users the database can support under what settings * We will improve the query/business logic affected * We can alarm on Hyperdrive errors ### **Action items** **Short term** * analyze improvements in Cloudflare worker setup - auditing everything against best practices e.g. setting `prepare=false` in Drizzle - owners @Cali Armut @Celine Sarafa ✅ * add Hyperdrive metrics to Cloudflare dashboard if possible and add an alarm on the errors - owner @Ben Kremer * Downscale Supabase instance to `4XL` - owner @Cali Armut * Set an alarm on Supabase connections - owner @Ben Kremer * Cover Serverless Database configuration and pool size in operational readiness checklist - @Ben Kremer **Mid-term** * implement query improvements from short-term analysis - owners for priortizing @Cali Armut * Properly productionize/provision the Hyperdrive setup \(currently not infra as code\) - owners @Cali Armut @Ben Kremer * Make sure `pool size` is well configured for replicas - owner @Ben Kremer **Long-term** * Split Cloud database from AppKit to prevent spillover # FAQ ### Did the outage cause any spillover to other systems?  Exhibit 5: Cloudflare worker availability Yes. But the AppKit API remained overall above 99.99% - usually it’s closer to 100%. ### Would increasing the pool size immediately not have resolved the Supavisor issue?  Exhibit 6: Lengthy and hard to find FAQ docs still make it vague whether Supavisor relies on or circumvents the `Pool size`. Yes most likely after scaling up the DB. But given vague docs from Supabase we were under the impression that Supavisor circumvents the `Pool size` setting. This assumption was because it’s a software as a service product and one would assume Supabase handles this for one. That’s also how the product is marketed.  Exhibit 7: Customer support response A lengthy customer support response is the only place that made clear to use that for Supavisor in `session mode` we do still need to manage the `pool size`. So yes, increasing the `pool size` to ~192 from the default of 25 after increasing the instance to `4XL` would 99% not have required us to migrate to Hyperdrive. The bug in Supavisor described above also mislead us. ### There was a similar outage during registrations - what was that again? [COE airdrop app September 25, 2024](https://www.notion.so/COE-airdrop-app-10b3a661771e805898b2d77555fd93f8?pvs=21) We were on Hyperdrive and didn’t upgrade the instance and ran out of pool size. We took an action and root caused correctly. But we should have taken another action which would have been scale vertically and then we would have discovered the `pool size` issue probably before.

Read the full incident report →

Started Nov 05, 2024, 11:00 PM UTC· resolved Nov 06, 2024, 12:00 AM UTC

1. resolved Nov 07, 2024, 12:36 AM UTC

   US East Relay nodes are experiencing a higher than usual influx of traffic that's overloading the system and degrading the experience for some customers.

Read the full incident report →

Started Nov 05, 2024, 08:00 AM UTC· resolved Nov 05, 2024, 08:00 AM UTC

1. resolved Nov 05, 2024, 08:01 AM UTC

   On November 4 at 3PM UTC, we implemented a semantic versioning (semver) check on the SDK version header on api.web3modal.com. As a result, requests from React Native SDK clients that were not cached received 500 errors. The issue was resolved by November 5 at 8AM, and React Native client requests have resumed normal processing.

Read the full incident report →

Started Nov 01, 2024, 10:19 AM UTC· resolved Nov 01, 2024, 12:48 PM UTC

1. investigating Nov 01, 2024, 10:19 AM UTC

   Requests to our walletconnect.com and walletconnect.org Explorer APIs are currently impacted by an apparent routing issue in Cloudflare's Hong Kong (HGK) data center.

2. resolved Nov 01, 2024, 12:48 PM UTC

   This incident has been resolved.

Read the full incident report →