Automations Command Center

The problem

The company ran hundreds of automations across Make.com, n8n and Fireberry CRM, and nobody could answer the two questions that mattered during an incident: what is broken, and what depends on it. Failures were found when a salesperson noticed a lead had gone missing — which meant the damage was already done and the cause was three systems upstream.

What I built

• Pulled the full automation inventory from the Make.com and Fireberry REST APIs and normalised three different platform shapes into one model.
• Derived the dependency graph by parsing each automation's modules for the webhooks, records and fields it reads and writes, then linking producers to consumers.
• Added health monitoring and error tracking on top of the graph, so a failure highlights the downstream chain instead of a single node.
• Shipped it as the team's daily operations tool rather than a report — it answers questions during an incident, not after one.

The hard part

Dependencies aren't declared anywhere

No platform tells you that a Make scenario feeds a Fireberry field that a second scenario later reads. That relationship only exists implicitly, in module configuration. Building the map meant inferring edges from configuration rather than reading them from an API, and accepting that inference is fallible — so the map shows how each edge was derived, and a wrong edge can be corrected rather than silently trusted.

Outcome

The graph surfaced chains nobody had documented, including cross-platform ones, and made a 2.6x platform overspend traceable to the specific flows responsible.