Most CRM outages are not dramatic. A certificate expires, a disk fills, a single DNS record points at a machine that was retired last quarter. What these have in common is that one small thing sat in the middle of every user’s request, and nobody had written it down as important. An audit for single points of failure is just the habit of finding those things before they find you.

Trace One Request, Not the Architecture Diagram

Architecture diagrams are tidy and usually out of date. Instead, pick one ordinary action, such as a sales rep opening a contact record, and trace what actually happens, hop by hop. Start at the user’s browser and keep going until you reach the disk the data lives on.

In practice the list is longer than people expect: DNS resolution, the TLS certificate, a load balancer or reverse proxy, the web or application tier, a session store, a cache, the database, file or attachment storage, and the identity provider that handles login. Then add the things the request does not touch but the CRM depends on anyway: the job scheduler, the outbound mail relay, the integration endpoints, and the backup system.

Use a real session, with the browser’s network tab open and a server administrator beside you. You will almost always find one hop nobody on the team could name.

Ask the Same Three Questions of Every Component

For each item on your list, ask:

1. If this disappeared right now, would users notice, and how quickly?
2. Is there a second instance that could take over, and has anyone ever seen it do so?
3. Who gets alerted, and do they know what to do?

The second question is where audits get honest. “We have a standby” and “we have watched the standby take over” are different statements. An untested failover is a hope with a configuration file attached.

The Usual Suspects

Some components turn up as single points in almost every environment.

The database. Often the one stateful piece, and the hardest to duplicate. Replication helps, but a replica that nobody has promoted in a drill is unproven.

Shared storage. Attachments, exports and generated documents frequently sit on one file server or one volume that the application tier all mounts.

Identity and login. If single sign-on is down, a perfectly healthy CRM is unreachable. Check whether there is a documented break-glass administrator account that does not depend on the identity provider.

Certificates and DNS. These fail on schedules, not at random. Expiry dates and record ownership belong in a calendar that more than one person watches.

People and credentials. One administrator who holds the only copy of a key, or the only knowledge of how deployment works, is a single point of failure that no hardware budget fixes.

Score the Risk Before Spending Anything

Redundancy costs money and adds complexity, and complexity causes outages of its own. So not every single point deserves removing. Rate each one on two simple axes: how likely it is to fail, and how bad the business impact is if it does. A component that fails rarely but stops all sales activity for a day belongs in a different bucket from one that fails often but only delays a nightly report.

Then pick the response deliberately. You can remove the single point with redundancy, shorten the recovery with a rehearsed procedure, or consciously accept the risk and write that decision down with a name next to it. All three are legitimate. Silence is the only bad choice.

A Worked Audit Table

Here is what a finished audit might look like for a generic mid-sized deployment.

Component	Redundant today?	Failover tested?	Impact if lost	Decision
DNS records	Provider-managed	N/A	Total outage	Add second owner, calendar review
TLS certificate	No	N/A	Total outage	Automate renewal, alert early
Load balancer	Pair	Yes	Total outage	Keep as is
Application servers	Two nodes	Yes	Degraded	Keep as is
Database primary	Replica exists	No	Total outage	Schedule promotion drill
Attachment storage	Single volume	No	Partial outage	Replicate or accept with restore plan
Identity provider	External service	N/A	Login blocked	Create break-glass account
Backup system	Single target	Restore tested	No immediate impact	Add offsite copy

Notice that several rows do not require buying anything. They require a calendar entry, a drill, or a decision.

A Hypothetical Example

Imagine a team of around eighty CRM users running an application tier on two servers behind a load balancer. On paper they are highly available. During the audit, tracing a single request reveals that both application servers store uploaded attachments on a folder mounted from one third machine, and that this machine is not in the monitoring system at all. A full disk or a failed volume there would break every record containing a file, while all dashboards stayed green.

The fix was modest: add the machine to monitoring with disk alerts, document a restore procedure, and put replicated storage on the next quarter’s plan. The audit did not make the system perfectly resilient. It made the risk visible and owned.

Keep the Audit Alive

An audit goes stale the moment the next change ships. Attach a short question to your change process: does this add a new dependency or remove a redundant one? Repeat the request trace once or twice a year, and after any major migration. Record failover drills with the date and the result, so the claim “this fails over” has evidence behind it.

Frequently Asked Questions

Is a single point of failure always bad? No. It is a risk to be assessed, not automatically a defect. If the impact is small or recovery is quick and rehearsed, accepting it can be the sensible and cheaper choice, provided the decision is written down.

Does running in the cloud remove single points of failure? It changes them rather than removing them. Managed services often provide redundancy you would otherwise build yourself, but you can still depend on one region, one account, one DNS configuration or one set of credentials. Check the provider’s current documentation for what each service actually guarantees.

How often should we repeat the audit? At least once a year, plus after major changes such as a migration, a new integration, or a change of hosting model. A lightweight review of the table each quarter keeps it from going stale.

What should we fix first? Start with items that are high impact, low effort and untested: expiring certificates, unmonitored dependencies and missing break-glass access. These usually cost time rather than money and remove real risk quickly.

Who should own the audit? Whoever is accountable for CRM availability, with input from the people who deploy, the people who run the database, and a business representative who can say what an hour of downtime actually costs.

Next Step

Book ninety minutes this week with one administrator, open a CRM record while watching the network tab, and write down every component in the path. Even before scoring anything, you will have a map your team does not currently have.