Duration: 2 days, 20 hours and 58 minutes

Affected Components: Web CDN, Marketing Site, Client, Media Proxy, API, Gateway

Sep 12, 18:33:56 GMT+0
Monitoring - We implemented a fix and are currently monitoring the result..

Sep 12, 18:22:46 GMT+0
Investigating - We are currently investigating this incident..

Sep 15, 15:20:35 GMT+0
Resolved - This incident has been resolved..

Sep 12, 20:26:04 GMT+0
Monitoring - We implemented a fix and are currently monitoring the result. You may have issues connecting to voice calls..

Sep 12, 20:46:38 GMT+0
Monitoring - We're starting to recover from some unexpected service disruptions. Thanks for bearing with us! If you're still having trouble loading the app or using some of its functionality, you might just need to wait a bit longer for [DNS]('wikipedia.org/wiki/Domain%5FName%5FSystem) changes to propagate. You can speed that up by [flushing your computer's DNS cache](https://www.bitdefender.com/consumer/support/answer/118898/) or restarting your computer..

Sep 12, 18:40:08 GMT+0
Investigating - We are currently investigating this incident..

Sep 12, 18:53:42 GMT+0
Identified - We are continuing to work on a fix for this incident. User-uploaded content was subject to DMCA takedowns and our CDN provider ended up suspending our entire DNS zone within 30 minutes of them receiving them, despite giving us a 48-hour deadline to delete this user-uploaded content from the platform. We condemn this unprofessional handling by our CDN provider and apologise for the inconvenience this causes you..

Duration: 3 days, 5 hours and 27 minutes

Affected Components: API

Sep 7, 20:57:52 GMT+0
Resolved - This incident has been resolved..

Sep 4, 15:31:21 GMT+0
Investigating - We are currently investigating this incident..

Sep 4, 16:51:54 GMT+0
Monitoring - We implemented a fix and are currently monitoring the result..

Duration: 3 hours and 57 minutes

Affected Components: Web CDN, Marketing Site, Client, Media Proxy, API, Gateway

Sep 4, 00:01:47 GMT+0
Resolved - This incident has been resolved..

Sep 3, 20:05:03 GMT+0
Investigating - We are currently investigating this incident..

Sep 3, 20:30:00 GMT+0
Identified - We are continuing to work on a fix for this incident..

Sep 3, 20:52:33 GMT+0
Identified - We are continuing to work on a fix for this incident..

Sep 3, 21:49:26 GMT+0
Identified - We are continuing to work on a fix for this incident..

Sep 3, 22:02:31 GMT+0
Monitoring - We implemented a fix and are currently monitoring the result..

Sep 3, 23:00:54 GMT+0
Monitoring - We're continuously monitoring the situation, and you should expect brief windows of intermittent failures and timeouts while we work to relieve the pressure on our web proxies. The cause is fairly specific. We have a series of nodes load balancing traffic to the main Fluxer infrastructure, which is handling everything without breaking a sweat. The problem is our web proxy layer, which is running out of memory under the unprecedented number of new WebSocket connections being established. Unfortunately, that means we don't get to show this new wave of users how stable Fluxer normally is. We're glad to welcome you to Fluxer, and if you'd like to support us financially, you can [become a Plutonium subscriber](http://fluxer.app/plutonium), [send a donation](https://fluxer.app/donate), or buy the Operator Pass for self-hosters once it becomes available. For now, though, you may run into intermittent issues reaching any of our web services. We're working as fast as we can. 🏃.

Duration: 8 minutes

Affected Components: API

Sep 1, 21:20:32 GMT+0
Investigating - We are currently investigating this incident..

Sep 1, 21:28:54 GMT+0
Resolved - This incident has been resolved..

Duration: 20 minutes

Affected Components: API

Sep 1, 20:53:42 GMT+0
Investigating - We are currently investigating this incident..

Sep 1, 21:13:24 GMT+0
Resolved - This incident has been resolved..

Duration: 13 minutes

Affected Components: API

Aug 28, 01:10:04 GMT+0
Investigating - We are currently investigating this incident..

Aug 28, 01:23:01 GMT+0
Resolved - This incident has been resolved..

Duration: 11 minutes

Affected Components: Gateway

Aug 25, 22:43:23 GMT+0
Investigating - We are currently investigating this incident..

Aug 25, 22:54:29 GMT+0
Resolved - This incident has been resolved..

Duration: 4 minutes

Affected Components: Web CDN, Marketing Site, Client, Media Proxy, API, Gateway

Aug 20, 01:47:44 GMT+0
Investigating - We are currently investigating this incident..

Aug 20, 01:52:01 GMT+0
Resolved - This incident has been resolved..

Duration: 14 minutes

Affected Components: Web CDN, Marketing Site, Client, Media Proxy, API, Gateway

Aug 18, 03:56:48 GMT+0
Investigating - We are currently investigating this incident..

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

Aug 18, 04:18:09 GMT+0
Postmortem - On 18 August, Fluxer was down for about 15 minutes, from 03:54 to 04:05 UTC. Traffic reaches us through Caddy. Caddy terminates TLS and forwards into Kubernetes via ingress-nginx. Page loads are served by app-proxy. Everything else goes to the API. On every page load, app-proxy refreshed a cached discovery document before responding. It fetched that document from its own public address, <https://api.fluxer.app/.well-known/fluxer>. The request therefore travelled back out through Caddy rather than staying inside the cluster. A rolling API deploy made that endpoint briefly unavailable. The fetch had a five second timeout, so every page load began taking five seconds. Those slow requests filled up ingress-nginx. They then filled Caddy's queue of pending connections, and Caddy stopped accepting new ones. At that point app-proxy could no longer reach the API at all. The route it needed ran through the front door it had just blocked. The outage held itself open and could not recover on its own. We restarted Caddy on all three web nodes to clear the backlog. That restored service. The root cause was in app-proxy. Its background refresh already backed off when the API was unhealthy. The page load path, however, called the refresh directly and skipped that backoff. Every request therefore paid the full timeout. Page loads now serve the cached document. They make no network calls at all while a cached copy exists. The first fetch after startup is rate limited, so an unavailable API cannot cause a retry storm..

Duration: 3 hours and 2 minutes

Affected Components: 🇧🇷 Brazil

Aug 17, 21:22:30 GMT+0
Investigating - We are currently investigating this incident..

Aug 17, 22:15:28 GMT+0
Monitoring - We implemented a fix and are currently monitoring the result..

Aug 18, 00:24:14 GMT+0
Resolved - This incident has been resolved..

Duration: 51 minutes

Affected Components: API

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

Aug 17, 20:23:39 GMT+0
Resolved - This incident has been resolved..

Duration: 1 hour and 26 minutes

Affected Components: API

Aug 14, 18:15:51 GMT+0
Resolved - This incident has been resolved..

Aug 14, 17:13:59 GMT+0
Identified - We are continuing to work on a fix for this incident..

Aug 14, 16:49:44 GMT+0
Investigating - We are currently investigating this incident..

Aug 14, 18:14:03 GMT+0
Monitoring - We implemented a fix and are currently monitoring the result..

Duration: 55 minutes

Affected Components: API

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..

Duration: 24 minutes

Affected Components: API

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..

Duration: 11 minutes

Affected Components: API

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..

Duration: 1 hour and 8 minutes

Affected Components: Web CDN, Marketing Site, Client, Media Proxy, API, Gateway

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..

Duration: 38 minutes

Affected Components: API

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..

Duration: 46 minutes

Affected Components: API

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..

Duration: 24 minutes

Affected Components: 🇮🇳 India

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..

Duration: 51 minutes

Affected Components: API, Gateway

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..

Duration: 10 minutes

Affected Components: 🇪🇺 EU East

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..

Duration: 16 minutes

Affected Components: Gateway

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..

Duration: 1 hour and 31 minutes

Affected Components: API, Gateway

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!.

Duration: 2 hours and 6 minutes

Affected Components: Media Proxy

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..

Duration: 19 minutes

Affected Components: API

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..

Duration: 2 hours and 30 minutes

Affected Components: Gateway

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!.

Duration: 1 hour and 12 minutes

Affected Components: Gateway

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..

Duration: 2 hours and 30 minutes

Affected Components: API, Gateway

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.

Duration: 2 hours and 45 minutes

Affected Components: API, Gateway

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_ ---.

Duration: 2 hours and 13 minutes

Affected Components: Client, Media Proxy, Web CDN, Gateway, API, Marketing Site

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..

Duration: 21 minutes

Affected Components: Gateway

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..

Duration: 19 minutes

Affected Components: Gateway

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..

Duration: 15 hours and 25 minutes

Affected Components: Client

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 - <https://bsky.app/profile/did:plc:tgm3isug3dbipufep4durid5/post/3mgrz7nqoms2o> 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..

Duration: 4 days, 23 hours and 4 minutes

Affected Components: Client, Media Proxy, Web CDN, Gateway, API, Marketing Site

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. 👀.

Duration: 2 hours and 50 minutes

Affected Components: Media Proxy, Marketing Site, API, Client, Web CDN

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..