# See what production is doing, and be allowed to act > A Databricks job fails overnight or the bill doubles, and nobody can say whether it matters or who's allowed to stop it. We add a layer over what Databricks already reports that ranks alerts by rules you write, traces spend to the jobs behind it, and lets the person who notices a problem act on it. Canonical: https://www.techfabric.com/solutions/production-visibility --- ## The alert fired. Then what. Monitoring answers whether something broke. The expensive questions are the three it does not. ### Nobody knows if it matters A job failed. Whether that breach is urgent, and to whom, is worked out by whoever happens to know what that job feeds. ### The person watching cannot act They can see it and not stop it. The person who can stop it is not looking. The gap between those two is where the money goes. ### The bill has no cause Spend doubled last quarter. Which jobs did it, and whether any of them produced anything anybody used, is a forensic exercise. Observation was never the hard part. Deciding what a signal means and who is allowed to respond to it is, and that is a governance problem wearing an operations hat. ## What we install ### Workload signals Job state, latency, cost and data quality collected as events rather than scraped from a dashboard. ### Severity from policy Whether a breach matters is evaluated against rules somebody wrote, not inferred by whoever is on call at the time. ### Interventions with authority Stopping a workload is an action with a policy in front of it, so the person who sees the problem can be the person who ends it. ### Cost attributed Spend traced to the jobs and teams that caused it, so a growing bill has a name rather than a mystery. ### Budgets that act A budget that stops a workload, rather than one that emails about it after the quarter closed. ### The response history What fired, who acted, under which policy. Reading the estate's past is a query rather than an archaeology project. ## Built for estates we were answerable for Radar came out of running Databricks workloads where somebody was going to ask us what happened and why. It is free and open source and it runs in your workspace. ## Questions ### We have monitoring already. What does this add? The two things monitoring does not do: decide whether a breach matters, and let the person who saw it act. Those are policy questions rather than metric questions, which is why a monitoring tool does not answer them. ### Will it actually stop a runaway job? If you give it the authority to. The design deliberately makes that your decision rather than the tool's, because a system that can stop production without anybody agreeing to it is its own incident. ### Does it work on estates we did not build? Yes, and that is most of them. It reads what Databricks already emits rather than requiring the workloads to be instrumented for it.