Identifying single points of failure in small web systems

Where can you find single points of failure in a small web system?

For each core process, infrastructure, external services, keys, data, people, and decisions are represented as a chain. A single point exists when its failure stops the process and no alternative can be executed within the required timeframe; a nominal backup without access does not count.

Impact-based priority

• Number of critical process links without an available alternative or backup within the required recovery time.

• Proportion of nominal backup paths whose access, data transfer, and minimum functionality have been confirmed in a real-world test.

Tested alternative

1. Select three to five critical user and operational processes and map their complete resource and decision chains.

2. Check each link for failure, common fault domain, available alternative, and measured changeover time.

3. Reduce the highest risks through secondary access, documented backup, isolation, or tested minimum operation.

Sole Person with Knowledge

• Sole Person with Knowledge – Only one service provider can modify deployment or DNS and is unreachable during the incident or has sole access.

• Shared Failure Domain – Primary service and supposed backup are in the same account, data center, or billing path and fail simultaneously.

• Untested Replacement – An alternative is contractually available but cannot quickly assume the data format, capacity, or required integration.

Expiration-Related Map

• Expiration-Related Map – Each core path contains technical services, data, access, responsible persons, and necessary approvals until recovery.

• Tested alternative – Replacement, manual operation, or recovery has been tested with real access points and within the required timeframe.

• Impact-based priority – Failure points are ranked according to stopped capability, duration of damage, and probability, rather than infrastructure size.

Cross-check: “Single person with knowledge”

The website runs on multiple instances, but DNS and domain account belong solely to a previous service provider. A server failure would be manageable, but account loss would not; therefore, ownership, secondary access, and documented provider changes are addressed before further server redundancy.

Related questions and next steps

An in-depth question answered Keep access, keys, and responsibilities up to dateHow can access points, keys, and technical responsibilities be reliably kept up to date?

Further Perspectives Plan for resilience based on business risk, not prestige.

If you want to practically implement "identifying single points of failure early," you can refer to Robust Website Systems This focuses on "Operation, Monitoring, and Recovery" and "Process-related mapping."

Conclusion: Identify single points of failure early

Failure points lie in processes, not just in hardware. Small systems often gain more resilience through secondary access and tested backups than through complex infrastructure.

Sources and Further Information

The following official documentation and standards provide the technical classification.

• SP 800-34 Rev. 1: Contingency Planning Guide – NISTOfficial NIST guide on impact analysis, recovery strategies, plans, testing, and exercises.

• Uptime and availability: keeping your service online – GOV.UK Service ManualOfficial guideline on redundancy, single points of failure, vendor dependencies, maintenance times, and user availability.

• Monitoring Distributed Systems – Google SREPrimary source of information on symptoms and causes, golden signals, actionable alerts, and the consequences of false alarms.