Why Does Access Fail While Services Are Running? Infrastructure Redundancy

The fact that a service is running on a server does not, on its own, show that users can reach it. An access issue we experienced at X Mind Solutions brought this distinction into sharp focus. Our services and servers were running, and our existing alerts indicated no problems; nevertheless, users could not access the service. In this situation, looking only at the system’s internal state is not enough. The connections and external dependencies along the path of a user’s request also need to be considered.

Our initial checks focused on the Docker environment, tunnels and server services. We examined the server and logs and confirmed that the Cloudflared process was running. However, these checks did not prove that the entire access path was healthy. A process being up and an end-to-end connection being possible through that process are two different things. A more effective troubleshooting approach therefore considers both “Is it running?” and “Can the user actually reach it?”

As the investigation continued, our attention shifted to infrastructure outside our own servers and an access issue in Frankfurt. However, without verified technical details about what happened in which component of a particular provider’s infrastructure, it would be inappropriate to state a definitive root cause. The key lesson is that external dependencies are also part of service continuity. Successful local checks do not mean there is no problem elsewhere in the connection chain; the scope of the investigation needs to be broadened accordingly.

To prepare for situations like this, it is important to align monitoring more closely with the user experience. In addition to monitoring server resources and service processes, external access checks can be planned. The aim is not simply to establish that a component is up, but to test whether the service can return the expected response. Checks performed from different access points can help reveal the difference between local system health and the availability users actually experience. This also makes it easier to define exactly what alerts measure.

Following this experience, one area we needed to evaluate was redundant systems built on different infrastructures. It is important to distinguish data backups from service redundancy: having a copy of the data does not mean user traffic can switch to an alternative system. At X Mind Solutions, we learned to question whether alternatives also converge on the same external dependencies. A sound plan should cover data consistency, failover conditions and failback steps, and its feasibility should be assessed through testing.