All systems are operational.
This page shows an overview of our system status.
Please keep in mind that all helpers do this voluntarily in their free time.
If you have any questions or specific problems, feel free to open a ticket in our helpdesk.
Last updated 2025-10-17 22:05:19
Last updated 2025-10-17 22:05:19
House A, CJD
Last updated 2025-10-20 00:33:27
House B, C, D, E, H, I, K, L, N, P, Q and FeM-Office
Last updated 2025-10-17 22:05:19
Ethernet sockets
Last updated 2025-10-20 01:42:36
FeM AdminDB and network services (DHCP, DNS...)
Last updated 2025-10-17 22:05:19
Last updated 2025-10-17 22:05:19
Mail servers, inboxes & list systems
Last updated 2025-10-17 22:05:19
Last updated 2025-10-17 22:05:19
Last updated 2025-10-17 22:05:19
All monitoring systems, e.g. Icinga, Grafana, ...
Last updated 2025-10-17 22:05:19
Storage systems for servers (e.g. Ceph, ha-storage)
Last updated 2025-10-17 22:05:19
Federated social network
View DetailsLast updated 2025-10-17 22:06:02
Internal Messenger
Last updated 2025-10-17 22:05:19
A Service to Sell Tickets and Manage Events
View DetailsLast updated 2025-10-17 22:05:19
A Mirror for some selected Linux Distributions
View DetailsLast updated 2025-10-17 22:05:19
A Browser based Video-Conferencing Software
View DetailsLast updated 2025-10-17 22:05:19
XMPP / Jabber Instant Messaging
View DetailsLast updated 2025-10-17 22:05:19
FeM Content Infrastructure
View DetailsLast updated 2025-10-17 22:05:19
Our homepage
View DetailsLast updated 2025-10-17 22:05:19
Federated Instant Messaging
View DetailsThe module has been replaced. We are currently working on the bootstrapping of all access points
The switch module was replaced. We are monitoring the situation and the status of all connected access points
A switch module in House H is having problems and thus some LAN ports are down.
All affected access points are up and working again.
We downgraded the version of our DHCP servers, now the accesspoints are starting up again, we're monitoring the situation.
While trying to investigate the failure source, we restartet a network switch in house K. Unfortunately this lead to more failed access points.
We have identified a component of our network management infrastructure to be the cause of this behavoir. The access points are manually reachable by our management infrastructure but are unable to broadcast wifi networks or handle traffic.
We are currently looking into the exact cause of this issue.
We have replaced multiple affected switch modules with working ones. All wired connections are back online. The access points have problems to be readded to the cluster. We are investigating this issue
We are currently preparing a physical restart of the affected switch module. We hope to finish the on-premise effort in the next hours.
We are having issues with one of the switch modules not being recognized by the switch therefore not powering up the access points. We are currently trying to restore the module state.
The situation was degraded overnight. There are currently many offline APs in house K which were unable to start up over night. We are working on a solution for this problem.
The integration rate has stabilized by now. Almost all access points are up again. We are monitoring the situation.
We are experiencing partial problems with some of the Aruba access points caused by slow inter-cluster-migration.
We have not found any problems with stability or the setup of access points. Therefore this incident has been resolved.
We were able to recover all crashed access points. We were able to setup all newly installed access points successfully.
We are monitoring the overall situation.
The deployed fix failed to hinder the misbehaving access point crashing half of the cluster again, which happend a few minutes ago.
We are working hard on recovering from this incident.
We have deployed the fix and are in the process of restoring access point setup operations.
We are in the process of deploying the aforementioned fix. We are monitoring the infrastructure and are ready to rollback the fix
We are currently working on a fix to hinder newly registered access points from crashing the cluster. We are planning to deploy this fix in the early evening.
The newly enabled access point did duplicated DHCP responses which failed about half of all access points in the FeM-Net. We were able to remove the access point physically.
Most of the access points are back online by now and we are trying to reproduce this behavoir in our testing network.
To prevent the same behavoir of other newly installed access points in House E we have disabled most of them.
Migrating the APs has lead to a cluster failure. We are investigating the causal context.
We are currently doing a manual on-premise-ap migration and setup into cluster mode.
Some newly installed access points do not join the access point management cluster as configured, because of network management issues, but rather create "stand alone mesh systems" which are unable to deliver any FeM-WiFi and accept traffic.
We are currently working on a solution for migrating these APs in our cluster.
We have identified a component of our network management infrastructure to be the cause of parts of this issue. Please see this incident regarding issues with unresponsive access points.
The access points do start the automatic configuration now, but fail midway. We are currently investigating this behavoir.
We have deployed a fix for our setup process. The newly installed access points should now undergo automatic setup. We are monitoring the situation
The access points seem to be unreachable by our DHCP server. We are currently working on a configuration update for the firewall and core router components to fix this issue.
We are experiencing issues with initial configuration of the newly installed wifi access points in house E.