Build a Blast Radius Map With ToolJet MCP

What Is a Blast Radius Console?

A shared spreadsheet only one person knows how to work slows blast-radius calls for a payments platform team. Build a blast radius map with ToolJet MCP to keep services, databases, queues, on-call owners and runbook links in one workspace.

By the end, you can trace degraded features, page the right teams and save the snapshot you need for the postmortem. The result is a structured ToolJet application with data, queries and interface together.

Page one with authorization-service selected: it turns red, the six services that depend on it light up, and the counters show two customer features hit and two teams to page.

Page two with fraud-scoring picked: its dependencies are listed for the owner to edit, and four saved snapshots show Match, Over-predicted, Missed and Awaiting actual, with map accuracy at 33%.

How Do You Map Service Blast Radius?

Map service blast radius by tracing the broken service through its dependency links, then keep degraded features, paging lists and runbook coverage in one view for the team. A coding agent can build it as a working app with ToolJet MCP.

1. List services, databases and queues around the broken service
2. Trace downstream dependencies and widen the radius when needed
3. Group affected services by team and identify runbook coverage
4. Record the snapshot with incident reference and note
5. Compare predicted impact with the actual services later

How Does the Impact Map Respond?

The screen starts with the selected service centered in a graph clustered by team, and the rest of the graph reacts around that choice. Search jumps to any service, clicking a node does the same, and the Reach control widens the view from the default two hops to the whole graph. Downstream dependencies light up, upstream dependencies stay grey and unrelated services fade. Under the map, the app shows degraded customer features, the teams to page and the affected services with runbook coverage.

A save snapshot action captures the incident reference and note for the postmortem. The second page keeps ownership edits next to saved snapshots and the actual impact so the comparison stays close to the dependency data, and each owner can add or remove links for the services they own.

• Team-clustered map of services, databases and queues
• Search any service or click a node to select it
• Reach widens the blast radius from two hops to the full graph
• Counters and tables show degraded features, paging targets and runbook coverage
• Owners edit dependencies and compare snapshots with actual impact

Build a Blast Radius Map With ToolJet MCP Walkthrough

Want to build it yourself? Start with the ToolJet MCP repository for setup instructions, supported agents, and everything you need to follow along.

How Do Iterations Become One Prompt?

The build took several passes, and the requirements are consolidated here into one prompt that could have been used from the start. That gives you a single specification to reproduce the same console in one shot without extra reshaping.

Use ToolJet Database with seeded sample data and only native ToolJet components. Page one, Impact Map: show services, databases, queues and owning teams as one connected map clustered by team. Let the user search for a service or click a node to select it. When selected, show that service as the broken one, light up downstream dependencies, keep upstream dependencies grey, and fade everything else. Show the selected service plus two hops by default, and add a Reach control for one hop, two hops, three hops or the full graph. Beside the map, show counters for affected services, degraded customer features, teams to page, and affected services without a runbook. Under the map, show customer features that are degraded, on-call teams to page with handles and hit counts, and affected services with runbook coverage and a link to the runbook. Add a Save snapshot action with an incident reference and a note. Page two, Dependencies: let each owner pick a service they own using their sign-in email, edit dependencies, add a dependency from a searchable list with sync, async or data, and remove one after confirmation. Show saved snapshots next to actual impact, with incident reference, root cause, predicted count, actual count and a verdict. Add a Record actual action that stores the real services impacted and updates the verdict. Show tiles for snapshot count, actual recorded and match rate. Create groups for Incident Responders and Service Owners. Incident Responders can explore, save snapshots and record actual. Service Owners can edit dependencies of the services they own. Everyone else in engineering can view. Gate write actions by group membership.

How Does ToolJet MCP Assemble The App?

ToolJet MCP documentation is the place to start, and ToolJet MCP documentation shows the flow if you want the agent to assemble the full app structure. The agent works through the data model, pages, components, queries and wiring between them, then the result lands as a real ToolJet application rather than something you still have to stitch together outside the platform, with the same data shape ready for later edits in the builder.

That matters here because the same runtime can carry data connectivity, workflows, permissions, deployment and ongoing change where supported, and the path stays open for AI generation, visual editing and code where a case needs it.

What Broke In The Snapshot Delete Flow?

Removing a dependency failed because a filtered ToolJet Database query needed an explicit sort order, and the snapshot dialog showed a default registration form. Adding the sort order fixed the delete flow, and the dialog now opens with the incident fields meant for snapshots.

What Does The Results Table Show?

The results table shows the selected service, the affected set, the degraded features, the paging list, the runbook coverage and the snapshot comparison for the current selection.

Which Teams Use This Impact Map?

Any engineering team that runs many services and loses the first minutes of an incident arguing about what else is affected: payments and fintech platforms, marketplaces, logistics and travel platforms, SaaS companies with many internal services, and platform or SRE teams that own a service catalog.

Who Can View And Edit The Console?

Two groups were created: Incident Responders and Service Owners, both with view access to the app. In the app, Save snapshot and Record actual are only enabled for Incident Responders, and Add dependency and Remove are only enabled for Service Owners; administrators can use all four. Service owners only see the services whose owner email matches their sign-in email. Everyone else in engineering can open and explore the map. ToolJet refused query-level permissions on this plan, so these checks are in the app, not enforced on the queries.

Self-Hosting ToolJet: Open Source, On-Premise and Air-Gapped Deployment

A Blast Radius Console app often works with data that cannot leave your network, and ToolJet lets you run the whole platform on infrastructure you control instead of a vendor cloud. Both the community edition and the enterprise edition can be deployed on-premise, and air-gapped deployment is available for environments with no internet access.

This console touches on-call handles, owner emails and incident references. Keeping those records on company infrastructure gives security and IT reviewers a single place to control access and track changes.

Self-Hosting ToolJet: Open Source, On-Premise and Air-Gapped Deployment

Deployment Options: Docker, Kubernetes and Major Clouds

ToolJet's self-hosting setup guides cover the common ways to run it in your own environment:

• Docker Compose deployment: run ToolJet on a single server, with optional Terraform scripts to provision a VM on AWS, Azure or GCP first.
• Kubernetes deployment: run ToolJet on your own cluster, with dedicated guides for EKS, GKE, AKS, Helm and OpenShift.
• Your own PostgreSQL: ToolJet stores app definitions, encrypted data source credentials and user authentication data in a PostgreSQL database that you manage.

Open Source Core and Air-Gapped Enterprise Deployments

• Open source community edition on GitHub: the ToolJet repository is released under the GNU Affero General Public License v3.0 (AGPL), so your team can inspect the code and self-host the community edition.
• Air-gapped deployment: run ToolJet in fully isolated environments without external network access, listed on the ToolJet Enterprise plan.
• ToolJet AI Enterprise: deploy the AI server image inside your own environment so AI requests are processed on your servers, which suits private-cloud and air-gapped setups.

Self-hosting keeps the Blast Radius Console app, its data and its credentials inside the network and security boundary your team already governs, and a self-hosted community edition can be upgraded to the enterprise edition when you need enterprise features.

Enterprise Features for Your Impact Console

A blast radius console carries owner emails, on-call handles, and incident references. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.

• SSO and SCIM: sign in with SAML, OIDC or LDAP, and provision users automatically
• Role-based access control: scope permissions to the app, the data source, and each query
• Audit logs: track every login, edit, and approval decision for compliance review
• Air-gapped deployment: self-host on Docker or Kubernetes so your data stays in your network
• Multiplayer editing: several builders work on the same app, with versioning and Git sync
• ToolJet AI inside your own deployment: run the AI features in your tenancy rather than a shared service

You could add a notification layer with ToolJet Workflows. For example, a workflow could fire when an impact snapshot is saved, post the root cause to the on-call team in Slack, email the incident owner through Gmail, and write the follow-up note back to dp_snapshots.

Final Takeaways

This build shows a blast radius console that turns a selected service into a live dependency map, then turns that map into paging lists, runbook checks, saved snapshots and a review page. The team can see which customer features are degraded, which on-call teams need attention, and whether the recorded impact matched the prediction at a glance.

For a platform engineering team, this blast radius map keeps the service graph, the review flow and the incident history in one editable ToolJet application instead of living in separate notes and spreadsheets.

Try ToolJet MCP

Build a blast radius map with ToolJet MCP, then request a ToolJet demo to map it onto your service data. Start free on [ToolJet Cloud].

FAQs

What does ToolJet MCP build for a blast radius console?

ToolJet MCP lets a coding agent turn a prompt into a working ToolJet application. For this pattern, the output includes the dependency map, the impact review page and the snapshot flow inside the same app, not just a screen.

How does the blast radius map respond to a selected service?

The selected service sits at the center, downstream dependencies light up, upstream dependencies stay grey and unrelated services fade. Search jumps to any service, clicking a node does the same, and Reach widens the view when you need more context.

What data tables does the blast radius console use?

It uses dp_teams, dp_nodes, dp_edges, dp_features, dp_feature_nodes and dp_snapshots. Those tables hold ownership data, dependency links, customer impact and the saved snapshot history for later comparison by service owners and responders across incidents and reviews.

Do I need to write code to change the console after the agent finishes?

No. You can keep refining the tables, queries and screens in ToolJet after the first build, and code is still available when a case needs it. That gives you a place to adjust the map or the dependency editor without starting over.

What happens to the console after the agent finishes?

The result is a structured ToolJet application, so the data model, pages and queries stay together on the runtime. That leaves the team with data connections, workflows, permissions, deployment and ongoing change where supported, instead of a loose build artifact.

How do I reproduce the console from the prompt?

Use the prompt with ToolJet MCP and seed the ToolJet Database tables for teams, nodes, edges, features, feature links and snapshots. The agent then assembles the map, the dependency editor and the access rules from the same specification.

Can several people work on the same console?

Yes. Incident responders can save snapshots and record actual impact, while service owners edit the dependencies they own in the same console. Everyone else in engineering keeps view access to the shared map and snapshots.