Database server
Where the failure starts.
What depends on what
Write down how a system is built: which servers and ports it uses, which outside services it calls, where it moves if the main site fails. Those links become a shared description, and they show what a change or an outage will hit before you learn it the hard way.
Usually one engineer knows, and that engineer is on holiday. AverDesk links servers, running copies of services, the services themselves and the products people use into one map the whole team can read (a dependency graph).
When something fails, AverDesk walks that map and shows what stops next. The team keeps the map up to date on a diagram instead of in a table.
Take the database server that went down at night. Here is how the trouble travels along the map.
Where the failure starts.
The copy of the service running on that server.
The app your people use. The links lead straight to it.
If A depends on B and B depends on A, nobody can tell where a failure starts. When a new link would close such a circle (a cycle), AverDesk refuses it and shows the exact path that closes it.
Try it below and see what the refusal looks like.
Existing path: Service B → Resource C → Service A
Service A → Service B → Resource C → Service A
The map stays free of circles. Check the existing links before you add this one.
Decide what can link to what and how many links of each kind are allowed. The map then follows the way your team actually thinks about its systems.
The map lists things linked to nothing and things that never reach any product people use. A daily check reports anything newly forgotten, so the map does not quietly fall apart.
Engineers keep the links up to date. The night shift (in a NOC, a network operations center) follows the chain when something fails. The person responsible for a service finally sees what it runs on without asking anyone.