Fluxer Status - Incident history

Issues with elevated API latency and errors

Mon, 10 Aug 2026 19:09:19 +0000

Type: Incident

Duration: 55 minutes

Affected Components:

Aug 10, 19:09:19 GMT+0
Investigating - We are currently investigating this incident..

Aug 10, 20:04:27 GMT+0
Resolved - This incident has been resolved..

Issues with elevated API latency

Wed, 5 Aug 2026 00:45:41 +0000

Type: Incident

Duration: 24 minutes

Affected Components:

Aug 5, 00:45:41 GMT+0
Investigating - We are currently investigating this incident..

Aug 5, 01:10:01 GMT+0
Resolved - This incident has been resolved..

Issues with elevated API errors

Fri, 31 Jul 2026 15:59:35 +0000

Type: Incident

Duration: 11 minutes

Affected Components:

Jul 31, 15:59:35 GMT+0
Investigating - We are currently investigating this incident..

Jul 31, 16:10:44 GMT+0
Resolved - This incident has been resolved..

Scheduled maintenance for infrastructure upgrades

Fri, 31 Jul 2026 01:00:00 +0000

Type: Maintenance

Duration: 1 hour and 8 minutes

Affected Components: , , , , ,

Jul 30, 14:35:00 GMT+0
Identified - We are planning for a scheduled maintenance to upgrade our Kubernetes cluster. You will be disconnected from Fluxer for a short period of time. This is **not** a user-facing update of our clients to the latest version. Stay tuned just a little while longer for that..

Jul 31, 01:00:01 GMT+0
Identified - Maintenance is now in progress.

Jul 31, 02:08:17 GMT+0
Completed - Maintenance has completed successfully..

Issues with elevated API errors on a subset of requests

Fri, 24 Jul 2026 21:04:04 +0000

Type: Incident

Duration: 38 minutes

Affected Components:

Jul 24, 21:04:04 GMT+0
Identified - We are continuing to work on a fix for this incident..

Jul 24, 21:42:07 GMT+0
Resolved - This incident has been resolved..

Issues with platform connectivity

Fri, 24 Jul 2026 07:44:54 +0000

Type: Incident

Duration: 46 minutes

Affected Components:

Jul 24, 08:30:31 GMT+0
Resolved - This incident has been resolved..

Jul 24, 08:34:21 GMT+0
Postmortem - Our infrastructure provider carried out emergency Linux security maintenance overnight, which forcibly restarted several production servers. This caused four separate incidents and woke Hampus, our on-call engineer, four times throughout the night. The final incident was the most severe, making our entire Kubernetes cluster unreachable and significantly affecting Fluxer's availability. Recovery was made harder when several services failed to restart cleanly after the forced reboots. Hampus worked through the night to restore the cluster, recover the affected services, and remove connection limits exposed during the restart process. Everything is now operational. We have improved automatic service recovery and increased connection capacity. We are sorry for the disruption, and grateful for everyone's patience while a very tired human worked to put out a series of infrastructure fires..

Jul 24, 07:44:54 GMT+0
Investigating - We are currently investigating this incident..

Issues with connecting to the India voice region

Sat, 18 Jul 2026 14:54:25 +0000

Type: Incident

Duration: 24 minutes

Affected Components:

Jul 18, 14:54:25 GMT+0
Investigating - We are currently investigating this incident..

Jul 18, 15:18:26 GMT+0
Resolved - This incident has been resolved..

Issues with elevated API errors and guild availability issues

Sat, 18 Jul 2026 11:02:12 +0000

Type: Incident

Duration: 51 minutes

Affected Components: ,

Jul 18, 11:02:12 GMT+0
Investigating - We are currently investigating this incident..

Jul 18, 11:12:27 GMT+0
Monitoring - We implemented a fix and are currently monitoring the result..

Jul 18, 11:53:40 GMT+0
Resolved - This incident has been resolved. You may need to refresh your client (Ctrl + R or reopen the app) to be reconnected to all your communities. We are working on triggering a forced reconnection across the entire backlog of stuck connections for those who have not yet refreshed their clients..

Jul 18, 12:56:33 GMT+0
Postmortem - On 18 July 2026 we had a significant partial degradation. One Kubernetes worker node appeared healthy from the outside but lost access to in-cluster service addresses, including cluster DNS, so every workload on it could no longer reach internal services or datastores. Because the node hosted many workloads, critical features were badly degraded while all of our monitored signals stayed green. The cause was an incorrect permission for the Kubernetes service proxy, which needs to list and watch node records to build internal routing rules. It was introduced on 27 May 2026 during a bulk re-apply of base cluster permissions from an out-of-date manifest set, which also disabled the automatic reconciliation that would have corrected it. The fault lay dormant for about seven weeks and triggered at roughly 06:01 UTC on 18 July, when that node's proxy restarted and could no longer rebuild its rules. We restored the correct permission and its reconciliation, and full service returned by about 11:45 UTC. The degradation lasted just under six hours. Because everything we monitored stayed green while critical paths were impaired, we are improving our monitoring to page on-call for partial degradations, including per-node reachability of cluster DNS and services, node-level workload health, and drift in critical permissions..

Issues with connecting to the Warsaw (EU East) voice server

Fri, 17 Jul 2026 15:06:48 +0000

Type: Incident

Duration: 10 minutes

Affected Components:

Jul 17, 15:06:48 GMT+0
Investigating - We are currently investigating this incident..

Jul 17, 15:17:08 GMT+0
Resolved - This incident has been resolved, connections to the EU East RTC region should now successfully establish..

Jul 17, 15:17:11 GMT+0
Resolved - This incident has been resolved..

Issues with joining new communities for a subset of users

Tue, 23 Jun 2026 22:20:46 +0000

Type: Incident

Duration: 16 minutes

Affected Components:

Jun 23, 22:20:46 GMT+0
Investigating - We are currently investigating this incident..

Jun 23, 22:37:07 GMT+0
Resolved - This incident has been resolved..

Jun 23, 22:39:37 GMT+0
Postmortem - A very small number of users who tried to join a guild during our earlier outages ended up in a corrupted state: they couldn't access the guilds they'd tried to join because the database and the guild service disagreed about whether they were actually members. We've now force-reloaded every guild across the cluster from the database, putting everything back in perfect sync with that squeaky-clean shine. This most likely didn't affect you: but if it did, you're welcome. You might need to refresh your client to get back in sync..

Issues with community availability, elevated API error rates

Tue, 23 Jun 2026 17:55:44 +0000

Type: Incident

Duration: 1 hour and 31 minutes

Affected Components: ,

Jun 23, 17:55:44 GMT+0
Investigating - We are currently investigating this incident..

Jun 23, 18:29:51 GMT+0
Resolved - This incident has been resolved..

Jun 23, 18:32:06 GMT+0
Postmortem - A sudden memory spike on guilds-2, one of our 12 guilds nodes, caused that node to be OOM-killed and triggered a thundering herd of guild restart requests against our API infrastructure. Until this point, we had not been aware of a bottleneck in the users service's routing layer, which processed messages serially. When the router picked up a request from the API to load a batch of users from the database (to populate the member lists in those guilds after a node failure such as this one), it waited for the request to be routed to a shard and to receive its reply. It did so without spawning a green thread in Tokio, so the wait blocked the main request loop in the router. We had only three router pods, which meant we could handle at most three concurrent requests to the users service. This had worked fine for a very long time. Under normal conditions our L1 cache absorbed the hits, so little or no work was done, and when work was done the requests were quick and did not run into timeout issues. When guilds-2 was OOM-killed, however, we received a flood of requests, all of which missed the cache. This was amplified by API retries, which overflowed the subscription queue into a permanent slow-consumer state, at which point NATS began dropping messages. The slow-consumer state then fed a second amplifier. NATS emitted a stream of slow-consumer events for the affected subscription, and our transport layer logged a warning for each one without any throttling. At the peak these warnings were firing at roughly 134 a second, and the logging alone burned enough CPU to slow the router further, which deepened the backlog and produced yet more slow-consumer events. With messages being dropped and the router starved, the API timed out, and requests that depend on the users service (including the logic to start a new session in the gateway) returned 500s. We restored service by scaling out the users service router capacity. We have since implemented a permanent fix, now being rolled out, in two parts. First, the router no longer blocks on the shard round-trip: it acquires a permit from a semaphore that caps the maximum concurrency and then spawns a green thread for each request, so the receive loop keeps draining the subscription at NATS speed rather than stalling on each shard reply. This mirrors the pattern our shard service already uses, where the same concurrency limit is set to 64\. Second, we throttled the slow-consumer warning to at most once per second, so it can no longer burn CPU and amplify a future incident. Thanks for your patience!.

Jun 23, 18:53:17 GMT+0
Monitoring - Some guild crashes are reoccurring and we are investigating..

Jun 23, 19:26:16 GMT+0
Resolved - We're so back!.

Jun 23, 21:02:37 GMT+0
Postmortem - As mentioned, the bottleneck in the users service (now fixed, and glad we caught it) was a secondary effect of the guilds-2 node being OOM-killed, not the cause. We initially assumed the OOM-kill was a one-off and closed the incident, but the root cause turned out to be different. The node spawned an unbounded worker for every async query. When a request came in for a guild's data, such as a member list, it started a separate lightweight worker so the guild's main process stayed responsive, but nothing capped how many could run at once. On top of that, each worker loaded its own copy of the guild data it was serving (the member list, plus every member's profile and presence), which for a very large community is a lot of memory per worker. When a burst of requests arrived together, as happens when many clients reconnect after a node restart, thousands of workers ran in parallel, each holding its own copy, and exhausted the node's memory, killing it and restarting the cycle. We've shipped two changes for this, both as no-downtime hot patches that are now live across the fleet. The first caps how many of these workers run concurrently. Extra requests now wait briefly for a free slot rather than all running at once, so memory stays bounded however large the spike. Since it went out, the previously affected node has held steady with no further restarts. The second removes the duplication at its source. Workers no longer hold their own copies of the guild's member data; they read from a single shared in-memory copy instead, so a worker's footprint is now a small fraction of what it was before. Between the two, a burst of requests can no longer balloon a node's memory the way it did here. Thanks for your patience!.

Issues with uploading media in the app

Wed, 17 Jun 2026 17:41:21 +0000

Type: Incident

Duration: 2 hours and 6 minutes

Affected Components:

Jun 17, 17:41:21 GMT+0
Investigating - We are currently investigating this incident..

Jun 17, 19:12:29 GMT+0
Monitoring - We implemented a fix and are currently monitoring the result..

Jun 17, 19:47:26 GMT+0
Resolved - This incident has been resolved..

Jun 17, 20:01:49 GMT+0
Postmortem - Uploads were temporarily, intermittently, unavailable because a background storage workload overwhelmed the capacity our API had reserved for storage requests, causing new uploads to wait too long and fail. We restored service by increasing that capacity and adding safeguards so background work cannot crowd out user uploads again..

Elevated API error latency

Mon, 15 Jun 2026 17:26:18 +0000

Type: Incident

Duration: 19 minutes

Affected Components:

Jun 15, 17:45:29 GMT+0
Resolved - This incident has been resolved..

Jun 15, 17:26:18 GMT+0
Investigating - We are currently investigating this incident..

Jun 15, 17:41:27 GMT+0
Monitoring - We implemented a fix and are currently monitoring the result..

Jun 15, 17:49:27 GMT+0
Postmortem - Slightly sleep-deprived, I shipped a typo in a configuration file. It slipped in while I was validating that everything still works with the latest changes for the self-hosting release I've been working on (due in 3-ish hours). Quickly caught and fixed..

Scheduled maintenance for real-time infrastructure improvements

Sun, 14 Jun 2026 01:30:00 +0000

Type: Maintenance

Duration: 2 hours and 30 minutes

Affected Components:

Jun 14, 01:30:00 GMT+0
Identified - Maintenance is now in progress..

Jun 14, 01:50:04 GMT+0
Identified - We're restoring access to the app as quickly as capacity allows. Hang in there!.

Jun 14, 02:19:10 GMT+0
Identified - We identified a bug with our new hotpatching system that was not caught in testing and are fixing this before finalising the rollout..

Jun 14, 03:00:35 GMT+0
Identified - We're monitoring recovery..

Jun 14, 03:36:36 GMT+0
Identified - All users have reconnected at this point, but we're diagnosing a bug with rapid presence oscillation. Member lists have been temporarily disabled in a select few guilds..

Jun 11, 04:44:52 GMT+0
Identified - The gateway has been running smoothly for the past 10 days, with no major issues. We've now got scheduled maintenance planned to move our gateway infrastructure onto a new code version. For context, that infrastructure is a cluster of 54 nodes spread across six specialised tiers for redundancy and load distribution, and it's served us very well. The new version introduces a system for safe, durable, and strongly consistent code updates that can roll out across the whole cluster in seconds, all through a standardised process that minimises human error. It also stabilises the wider deployment pipeline, should we ever need to carry out a rolling deployment of our stateful tiers. Our lead scientist, Rick Sanchez, reckons it'll be a quick twenty-minute adventure, in and out, though you might want to take that with a pinch of salt. The work we've put into boosting our backend's performance and helping it absorb load means we can promise a faster recovery time than on previous occasions. Once this new durable hotpatch deployment system is in place, we shouldn't ever need to "restart Fluxer" again, unless something catastrophic triggers cascading failures in our real-time stack. We're aiming for that 99.99% uptime!.

Jun 14, 03:58:06 GMT+0
Completed - Maintenance has completed successfully. It took some time to identify an edge case where if you had a DM open with the system user ("Fluxer"), you were actually not reconnected properly, hence the presence oscillation. We're now all back again. Thanks for your patience!.

App connection issues

Sun, 31 May 2026 14:51:06 +0000

Type: Incident

Duration: 1 hour and 12 minutes

Affected Components:

May 31, 15:23:32 GMT+0
Monitoring - A fix has been applied and we are monitoring recovery..

May 31, 16:02:38 GMT+0
Resolved - This incident has been resolved..

May 31, 14:51:06 GMT+0
Investigating - We are investigating reports of issues with connecting to the app..

May 31, 15:29:41 GMT+0
Monitoring - A fix has been applied and we are monitoring recovery..

May 31, 16:29:12 GMT+0
Postmortem - A gateway deploy caused widespread connection failures after several gateway tiers drifted out of sync. We recovered by bringing the affected tiers back onto one consistent build and reconciling the gateway cluster. We are tightening deployment and restart handling so runtime fixes are not lost during recovery..

Gateway event delivery issues

Sat, 30 May 2026 20:22:56 +0000

Type: Incident

Duration: 10 minutes

Affected Components:

May 30, 20:22:56 GMT+0
Identified - We have identified the cause and are working on a fix..

May 30, 20:33:10 GMT+0
Resolved - This incident has been resolved..

May 30, 20:34:00 GMT+0
Postmortem - Live updates stopped reaching some clients because gateway tiers were running mismatched protocol versions. We restored delivery by moving all gateway tiers onto the same build. Future gateway changes are being rolled into versioned releases deployed consistently across the fleet..

Community availability issues

Thu, 28 May 2026 19:53:14 +0000

Type: Incident

Duration: 30 minutes

Affected Components:

May 28, 19:53:14 GMT+0
Investigating - We are investigating reports of issues with some communities becoming unavailable..

May 28, 20:23:21 GMT+0
Resolved - This incident has been resolved..

App connection issues

Thu, 28 May 2026 13:56:10 +0000

Type: Incident

Duration: 3 hours and 15 minutes

Affected Components:

May 28, 13:56:10 GMT+0
Investigating - We are investigating reports of issues with connecting to the app..

May 28, 14:10:41 GMT+0
Identified - We have identified the cause and are working on a fix..

May 28, 15:03:05 GMT+0
Monitoring - A fix has been applied and we are monitoring recovery..

May 28, 17:10:55 GMT+0
Resolved - This incident has been resolved..

Scheduled maintenance for cluster capacity expansion

Sun, 24 May 2026 17:00:00 +0000

Type: Maintenance

Duration: 2 hours and 30 minutes

Affected Components: ,

May 24, 17:00:00 GMT+0
Identified - We are planning for a scheduled maintenance during that time..

May 24, 17:00:01 GMT+0
Identified - Maintenance is now in progress.

May 24, 17:58:40 GMT+0
Identified - We'll need another thirty minutes to safely let traffic back in after we tweak the Erlang VM settings across all our hosts. Thanks for your patience!.

May 24, 18:00:38 GMT+0
Identified - We're now rolling out the final updated image across our stateful real-time cluster..

May 24, 18:09:41 GMT+0
Identified - We're now letting people back in in \~\~waves\~\~..

May 24, 18:17:50 GMT+0
Identified - We let people back in a little bit too quickly. Stabilising and resuming the rollout..

May 24, 18:59:59 GMT+0
Identified - We're increasing the rollout gradually..

May 24, 19:30:00 GMT+0
Completed - Maintenance has completed successfully.

Elevated API latency after maintenance

Sun, 24 May 2026 01:17:28 +0000

Type: Incident

Duration: 1 hour and 23 minutes

Affected Components:

May 24, 01:17:28 GMT+0
Investigating - We are investigating reports of elevated API latency while reconnecting traffic settles..

May 24, 01:35:35 GMT+0
Identified - We have identified the remaining latency source and are deploying a fix..

May 24, 02:40:57 GMT+0
Resolved - This incident has been resolved..

Scheduled maintenance for stability patches

Sat, 23 May 2026 22:15:00 +0000

Type: Maintenance

Duration: 2 hours and 45 minutes

Affected Components: ,

May 23, 22:15:00 GMT+0
Identified - We are planning for a scheduled maintenance during that time..

May 23, 22:15:01 GMT+0
Identified - Maintenance is now in progress.

May 23, 22:45:56 GMT+0
Identified - This is your captain speaking. We're briefly pausing traffic to stabilise our backend infrastructure, rescheduling some workloads to make things more resilient against failures down the road. We'll have you back in the air shortly. Thanks for flying Fluxer..

May 23, 23:16:23 GMT+0
Identified - _ding_ Ladies, gentlemen, and variations thereupon, this is your captain again. You may have noticed we're still parked at the gate, and I wanted to give you a quick update! We're going to extend our maintenance window by about an hour. We're not expecting to need all that time, though. So sit back, relax, and we appreciate your patience. We'll keep you posted the moment anything changes. Thanks again for flying Fluxer. _ding_.

May 24, 00:11:48 GMT+0
Identified - We need yet another 30 minutes to stabilise the aftermath of the new rollout. Sessions are being admitted back, but guilds are crashlooping. Investigating..

May 24, 01:00:00 GMT+0
Completed - Maintenance has completed successfully.

May 24, 01:01:10 GMT+0
Completed - _ding_ Ladies, gentlemen, and variations thereupon, this is your captain speaking one last time. We've made it. The cabin doors are open and the seatbelt sign is off, so you're free to move about the platform. Sessions are back and the guilds have stopped crashlooping, so everything's running again. This took longer than any of us wanted, and we really do appreciate you waiting it out with us. If anything feels off as you settle back in, let us know at [support@fluxer.app](mailto:support@fluxer.app). Thanks for your patience tonight, and as always, thanks for flying Fluxer. _ding_ ---.

Brief app connection instability

Sat, 23 May 2026 19:48:02 +0000

Type: Incident

Duration: 1 hour and 41 minutes

Affected Components:

May 23, 21:28:43 GMT+0
Resolved - This incident has been resolved..

May 23, 21:28:44 GMT+0
Resolved - This incident has been resolved..

May 23, 19:48:02 GMT+0
Identified - We have identified the cause and are applying fixes..

May 23, 20:00:40 GMT+0
Monitoring - We are monitoring recovery and applying follow-up fixes for remaining instability..

May 23, 20:55:31 GMT+0
Monitoring - We are monitoring recovery and applying follow-up fixes for remaining instability..

May 23, 21:06:01 GMT+0
Monitoring - We are monitoring recovery and applying follow-up fixes for remaining instability..

Session start issues

Fri, 22 May 2026 15:03:35 +0000

Type: Incident

Duration: 27 minutes

Affected Components:

May 22, 15:25:37 GMT+0
Monitoring - A fix has been applied and we are monitoring recovery..

May 22, 15:30:39 GMT+0
Resolved - This incident has been resolved. Refreshing the client may reconnect you sooner..

May 22, 15:03:35 GMT+0
Investigating - We are investigating reports of issues with starting new sessions..

May 22, 15:16:30 GMT+0
Identified - We have identified the cause and are working on a fix..

May 22, 15:31:47 GMT+0
Postmortem - A backend change caused session clean-up work to consume more resources than expected. We rolled back and adjusted the implementation, then monitored recovery until new sessions were starting normally..

Gateway connection issues

Thu, 21 May 2026 00:24:18 +0000

Type: Incident

Duration: 56 minutes

Affected Components:

May 21, 01:00:28 GMT+0
Monitoring - A fix has been applied and we are monitoring recovery..

May 21, 00:24:18 GMT+0
Investigating - We are investigating reports of issues with connecting to the gateway..

May 21, 01:20:26 GMT+0
Resolved - This incident has been resolved..

May 21, 02:13:48 GMT+0
Postmortem - A load balancer reload triggered a large reconnect wave and exposed a gateway clustering bug in session resume handling. We recovered by controlling new session traffic, rolling affected services, and patching gateway resume logic. Session resume is now cluster-aware..

Voice channel disconnects

Wed, 20 May 2026 18:02:13 +0000

Type: Incident

Duration: 1 hour and 33 minutes

Affected Components:

May 20, 18:02:13 GMT+0
Investigating - We are investigating reports of issues with unexpected voice channel disconnects..

May 20, 19:35:00 GMT+0
Resolved - This incident has been resolved..

May 20, 19:35:18 GMT+0
Postmortem - A voice-state routing bug caused parts of the system to disagree about who was connected to voice channels. We disabled the unsafe reconciliation path and patched routing so voice state is checked across the full voice fleet. We are adding safeguards and monitoring for similar drift..

App connection issues

Wed, 20 May 2026 02:07:43 +0000

Type: Incident

Duration: 1 hour and 12 minutes

Affected Components:

May 20, 02:07:43 GMT+0
Monitoring - We are gradually reconnecting users and monitoring gateway recovery..

May 20, 02:22:30 GMT+0
Monitoring - We are gradually reconnecting users and monitoring gateway recovery..

May 20, 02:32:31 GMT+0
Monitoring - We are gradually reconnecting users and monitoring gateway recovery..

May 20, 03:19:45 GMT+0
Resolved - This incident has been resolved..

May 20, 02:44:07 GMT+0
Monitoring - We are gradually reconnecting users and monitoring gateway recovery..

May 20, 03:09:41 GMT+0
Monitoring - We are gradually reconnecting users and monitoring gateway recovery..

May 20, 02:27:36 GMT+0
Monitoring - We are gradually reconnecting users and monitoring gateway recovery..

May 20, 03:03:00 GMT+0
Monitoring - We are gradually reconnecting users and monitoring gateway recovery..

May 20, 02:37:20 GMT+0
Monitoring - We are gradually reconnecting users and monitoring gateway recovery..

May 20, 02:52:50 GMT+0
Monitoring - We are gradually reconnecting users and monitoring gateway recovery..

May 20, 02:58:23 GMT+0
Monitoring - We are gradually reconnecting users and monitoring gateway recovery..

May 20, 03:21:46 GMT+0
Postmortem - Fluxer now runs the gateway across multiple replicas and physical machines. This reduces the impact of a single gateway node failing and gives us more room to recover connections gradually..

Gateway connection issues

Tue, 19 May 2026 01:10:54 +0000

Type: Incident

Duration: 29 minutes

Affected Components:

May 19, 01:40:01 GMT+0
Resolved - This incident has been resolved..

May 19, 01:10:54 GMT+0
Investigating - We are investigating reports of issues with connecting to the gateway..

May 19, 02:09:32 GMT+0
Postmortem - A live gateway patch was not present in the deployed image, so a restart removed it and disconnected users. The reconnect wave then overloaded session start paths. We restored service with a full image deploy and controlled reconnection, and we are moving away from fragile live-only gateway fixes..

May 19, 01:31:40 GMT+0
Monitoring - A fix has been applied and we are monitoring gateway recovery..

Gateway session start issues

Mon, 18 May 2026 14:10:04 +0000

Type: Incident

Duration: 12 minutes

Affected Components:

May 18, 14:12:55 GMT+0
Identified - We have identified the cause and are rolling out a fix..

May 18, 14:10:04 GMT+0
Investigating - We are investigating reports of issues with starting new gateway sessions..

May 18, 14:19:57 GMT+0
Monitoring - A fix has been applied and we are monitoring recovery..

May 18, 14:22:12 GMT+0
Resolved - This incident has been resolved..

May 18, 14:39:31 GMT+0
Postmortem - Gateway requests were being forwarded without the real client IP, which caused unrelated traffic to be grouped under one rate-limit bucket. We fixed the forwarded IP handling and updated abuse protection so reserved ranges cannot be blocked..

Email claim issues during sign-up

Sun, 17 May 2026 15:36:49 +0000

Type: Incident

Duration: 22 minutes

Affected Components:

May 17, 16:02:54 GMT+0
Postmortem - An email ownership change treated in-progress reservations as conflicts, blocking some account and email updates. We reordered the checks, cleared affected rate limits, and audited ownership records for stale entries..

May 17, 15:49:40 GMT+0
Monitoring - A fix has been applied and we are monitoring recovery..

May 17, 15:59:17 GMT+0
Resolved - This incident has been resolved..

May 17, 15:36:49 GMT+0
Investigating - We are investigating reports of issues with claiming or confirming email addresses during sign-up..

Scheduled maintenance

Mon, 11 May 2026 22:00:00 +0000

Type: Maintenance

Duration: 2 hours and 13 minutes

Affected Components: , , , , ,

May 11, 22:00:00 GMT+0
Identified - We are planning for a scheduled maintenance during this time..

May 11, 22:00:01 GMT+0
Identified - Maintenance is now in progress.

May 12, 00:13:05 GMT+0
Completed - Maintenance has completed successfully..

Improving hardware allocation to the real-time gateway

Tue, 24 Mar 2026 17:30:00 +0000

Type: Maintenance

Duration: 21 minutes

Affected Components:

Mar 24, 17:30:00 GMT+0
Identified - We are planning for a scheduled maintenance during this time. You may be frequently disconnected from the service..

Mar 24, 17:51:18 GMT+0
Completed - Maintenance has completed successfully..

Fixing intermittent failures when sending messages in large communities

Fri, 20 Mar 2026 17:45:00 +0000

Type: Maintenance

Duration: 19 minutes

Affected Components:

Mar 20, 17:45:00 GMT+0
Identified - Communities may disappear and come back. We apologise for the inconvenience..

Mar 20, 18:03:33 GMT+0
Completed - Maintenance has completed successfully..

Upgrading the real-time and media infrastructure

Wed, 11 Mar 2026 13:40:00 +0000

Type: Maintenance

Duration: 15 hours and 25 minutes

Affected Components:

Mar 11, 18:41:20 GMT+0
Identified - If your client crashed just recently, that was our fault, not yours! Everyone received a bad payload over their WebSocket connection and was forced to reload. Sorry!.

Mar 11, 13:40:00 GMT+0
Identified - Member lists have been disabled globally to shed some load to make the platform a bit more usable (the member list is the bane of my existence) in preparation for the next deploy that will let us bring them back, HQ back, improve loading times of media, eliminate random failures and intermittent latency, and a lot of other cool things!.

Mar 11, 21:39:31 GMT+0
Identified - We're finishing up some remaining things caught in testing before rolling this out to everyone! Stay tuned 👀.

Mar 12, 05:04:47 GMT+0
Completed - We're still working on this! Member lists will remain disabled for a bit longer. Thanks for your patience — we want this upgrade to go as smoothly as possible so we're taking extra care to work out the remaining issues found during testing..

API Migration (Part 2!)

Tue, 24 Feb 2026 12:00:00 +0000

Type: Maintenance

Duration: 4 days, 23 hours and 4 minutes

Affected Components: , , , , ,

Feb 28, 04:22:34 GMT+0
Identified - We're still in the process of working on the migration, but we've flipped over all of the infrastructure to the new stuff now! We're working on some bugs still, but we should still be on track for 10 AM UTC on Saturday..

Mar 1, 11:04:26 GMT+0
Completed - Maintenance has completed successfully..

Feb 26, 14:34:25 GMT+0
Identified - We're still working on fixing some some bugs with the updated gateway, which are causing all guilds to become unavailable on certain changes and making the platform unstable for brief periods of time before we roll it out to a wider audience..

Feb 26, 19:41:15 GMT+0
Identified - The media proxy and the static assets remain stable on the new infrastructure, so both are being marked operational now. We are continuing to have a subset of traffic hitting the new infrastructure and hope to fully cut it over soon..

Feb 24, 12:00:00 GMT+0
Identified - We are planning for a scheduled maintenance during this time to complete the migration of the infrastructure. We hope to keep the platform online as much as possible throughout this transition..

Feb 24, 12:00:01 GMT+0
Identified - Maintenance is now in progress.

Feb 24, 14:21:09 GMT+0
Identified - The infrastructure migration is still in progress and the maintenance window has been extended by an hour to accommodate needs..

Feb 24, 20:01:47 GMT+0
Identified - We're finally ready to start cutting over traffic! Things will continue to be a little bumpy as we sort out and scale up the new infrastructure, and may become unavailable entirely for some users for a short period. If you are using the official client and you're not let back in, please try to hit \[CTRL\] + \[R\] (or \[**⌘**\] + \[R\] if you're a Mac user) to reload it to see if that solves the issue..

Feb 25, 09:26:13 GMT+0
Identified - Sorry for the lack of updates, we've been heads down working on getting everything online and haven't had time to get the status page properly updated. We're almost to the point where things are in working order, however, there's an existing issue with the client not loading properly that we are working on fixing..

Feb 27, 21:46:29 GMT+0
Identified - Just wanted to share an update here for everyone watching alongside at home that we're still working on things behind the scenes..

Feb 25, 20:20:57 GMT+0
Identified - The maintenance is still underway, however preliminary testing with the new infrastructure has been well! We hope to be fully online again with a little treat for everyone soon. 👀.

API Migration

Tue, 24 Feb 2026 02:00:00 +0000

Type: Maintenance

Duration: 2 hours and 50 minutes

Affected Components: , , , ,

Feb 24, 02:00:00 GMT+0
Identified - We are working on migrating Fluxer to newer infrastructure. Stay tuned..

Feb 24, 04:49:35 GMT+0
Completed - Maintenance will be ending shortly but work will continue on the web client in the meantime. The progress of the migration will resume tomorrow morning as things have stabilized for this evening..