shadcn.io is not affiliated with official shadcn/ui
Service Dependencies Dashboard Block for Ark UI
Nine services listed as a tree by what they call, a Failing switch on each that marks every dependent as impacted with its depth, and a derived list of single points of failure.
Installation
Overview
Switch a service off and read the damage with this dependency panel for React with Ark UI. A hairline frame with a plus mark on each corner lists nine Linkweave services as a tree by what they call, each with a "Failing" Switch. Turn one on and every service that depends on it, directly or through others, reads "Impacted (depth 2)", counted from the nearest failure. Several failures combine, and "Clear" puts everything back. The side cell says in a polite line what is failing and impacted, and lists the single points of failure: the services whose failure would impact three or more others, worked out from the same call edges. It's built from Switch, Button and Guides. For platform teams planning incidents and game days.
FAQ
How do I fill it with my services?
Edit SERVICES: an id, the services it calls and its depth in the tree. A service shows once, under the first service that calls it, and its "Calls" line lists all its callees. Impact, the header, the side cell and the single points of failure are worked out from calls.
What does depth mean?
It is the number of hops from the nearest failing service to the dependent. A service that calls a failing one directly is depth 1, and one that calls that service is depth 2. With several failures a service takes the smallest depth.
How is a single point of failure chosen?
For each service the page walks the call edges backwards and counts how many others it would impact. A count of SPOF_AT (3) or more lists it, most impact first. The list does not change when you switch services, because it describes the graph, not the current failures.
What stays local, and how do I wire it for real?
Everything: the edges are typed and no service is probed or stopped. To wire it, build SERVICES from your service catalogue or traces, and keep the Failing switches as what-if toggles, or feed them from your live status.