Blast Radius Mapping: Scoping Which Site Features Fail Together
Most small sites do not fail as one thing. A slow database query makes the checkout page hang, a stale DNS record breaks the contact form, and a plugin update quietly disables login for half the staff. The useful question is rarely whether the site is up. It is how far a single failure reaches. This article walks through blast radius mapping, a way of tracing which features share a failure path so a small team can decide where to invest attention. It makes no claims about any particular provider's internal architecture, because the method works from what you can observe and document about your own setup.
Start With a Feature Inventory, Not a Diagram
Before drawing anything, list the features people actually use. For a typical small business site that usually means the public pages, a contact or lead form, a login area for customers or staff, a checkout or booking flow if one exists, email sending for notifications, and any embedded third-party widgets such as maps, chat, or analytics. Write each one as a sentence describing what a visitor does and what should happen. A feature you cannot describe in one sentence is often one nobody on the team fully understands, which is itself a finding.
Keep the list short enough to review in one sitting. Ten to fifteen items is typical. The goal is a shared vocabulary for the rest of the exercise, so that when someone says the form is broken, everyone knows which path they mean.
Trace Each Feature to Its Dependencies
For every feature, ask what has to work for it to succeed. Does the contact form need the database, an outbound mail service, a CAPTCHA provider, and the theme's JavaScript bundle? Does the login page depend on a session store, a password hashing library, and a redirect rule in the web server configuration? Write these as a simple list beside each feature. Do not try to be exhaustive on the first pass. Capture the dependencies you know about and mark the ones you are unsure of with a question mark.
The unsure items matter most. They are where surprises live. A common finding is that two unrelated features turn out to share a dependency nobody thought of, such as a single caching layer or a shared outbound email account that gets rate-limited when one feature sends a burst of messages.
Find the Shared Nodes
Now read down the dependency lists and look for repetition. Any component that appears under three or more features is a shared node, and a failure there has a large blast radius. Shared nodes in small setups tend to be the database, the email path, authentication, the theme or template layer, DNS, and certificate handling. None of these is a defect in itself. They are simply the places where one fault can touch many visitors at once.
Rank the shared nodes by two factors: how many features depend on them, and how hard they are to diagnose or restore when they fail. A node that is widely shared and opaque to your team deserves attention first. A node that is shared but well understood and easy to check may only need a documented note.
A Practical Triage Checklist
Once the map exists, a short checklist turns it into decisions. Work through these questions for each high-ranking shared node:
1. Who on the team can explain, in plain terms, what this node does and what breaks when it fails?
2. Is there a written record of how it was configured, and where that record lives?
3. If it fails, which features fail with it, and which visitors or internal users notice first?
4. Is there a check that would tell you it is failing before a visitor reports it, and who receives that signal?
5. Who has the access needed to change or restore it, and is that access documented somewhere other than one person's memory?
6. Which features could be decoupled or degraded gracefully, so that a failure in one place does not take down unrelated pages?
A node that scores poorly on questions one, two, or five is a knowledge risk. A node that scores poorly on four is a detection risk. Both are worth addressing, often with cheaper steps than a new architecture, such as writing a one-page note or assigning a named backup owner.
Questions to Ask Your Hosting Provider
Some dependencies sit outside your control, and the map should say so. When you review a hosting plan, whether shared hosting, managed WordPress, or a VPS, ask the provider direct questions about the parts of the stack you depend on. What does the plan include for the web server, database, email sending, and DNS? Which of those are managed for you, and which are your responsibility? What is the process for requesting help when something in the shared layers fails, and what information should you have ready when you ask?
Compare plans on the basis of what your map says you need. A site with a small number of shared nodes and low change frequency may fit a simpler plan. A site where the database and email path are both critical and tightly coupled may justify asking harder questions before committing. Do not assume that a plan label tells you what is covered. Read the plan details and confirm them in writing where it matters.