Cross-System Signal Radar: Triage Incidents in Code, Not Six Dashboards

Forty-five minutes. That is what most engineering directors pay every morning before standup, walking the same loop: Jira, then GitHub, then Slack, then Asana, then a spreadsheet someone pinned in a chat room three weeks ago. The output is a mental model of what needs intervention. Half of what gets flagged is fine.

That loop is a manual triage pipeline running on the most expensive infrastructure in the org. It is also the wrong shape. Reading dashboards trains you to pattern-match against yesterday's picture. The signals that matter are the ones that changed overnight, and the human eye is bad at deltas.

The replacement is structural. Five collector subagents fan out across five systems in parallel. An orchestrator pulls the payloads, cross-references them, scores confidence, and emits a 90-second brief tagged RED, AMBER, GREEN. Total wall-clock: under a minute. The pipeline finishes before the laptop opens.

For a director scanning five or more tools, the time recovered lands somewhere between 30 and 60 minutes a day.^[3] The actual gain depends on how many surfaces you currently check and how disciplined the team is about keeping them current — claim the time savings only after you measure them. The bigger payoff is harder to count: signals that crossed system boundaries overnight no longer require a human to notice them.

Dashboards were designed for SOC analysts and on-call engineers — people whose job is to stare at the screen. Engineering leaders are not those people. They context-switch between hiring, architecture review, stakeholder management, and the next quarter's plan. A dashboard demands continuous attention. A leader needs a processed conclusion.

The 2025 SANS Detection & Response Survey clocks 46% of all alerts as false positives.^[1] Engineering operations track close to that number. Stale PRs blocked on a design call. "Blocked" Jira tickets nobody bothered to close. Asana tasks marked overdue that the team intentionally deprioritized. Signal-to-noise is bad on every surface, and it compounds across them.

The average org runs eight observability tools.^[2] For a director overseeing 40 to 80 engineers across squads, that is eight tabs, eight notification channels, eight mental models — all kept warm in the background while real work happens. The cost is not the time per tool. The cost is the cognitive overhead of holding the union of all of them in working memory before the first 1:1 of the day.

Context-switching between tools is the number-three productivity killer for developers, according to Atlassian's survey of 3,500 engineers.^[7] For engineering leaders the number is structural: every manual triage loop is a pre-meeting scramble plus the cognitive cost of rebuilding a mental model from scratch. The morning dashboard ritual does not make better decisions. It delays them.

Three layers, sharply separated:

Layer 1 — Collectors run as parallel Claude Code subagents. Each one talks to exactly one system and returns a normalized signal payload. They run simultaneously, so total collection time equals the slowest API response (usually 3–8 seconds), not the sum of all five.^[5]

Layer 2 — Orchestrator receives the five payloads, cross-references them (a blocked Jira ticket and a stale PR on the same feature is worse than either alone), runs a confidence scoring pass, and assigns RED/AMBER/GREEN.

Layer 3 — Output formats the brief as a concise summary delivered to a chosen channel — email, Slack, or a pinned Google Doc that updates daily.

The coupling rule is non-negotiable: collectors know nothing about each other. Adding a sixth source means writing one new collector file, not refactoring the orchestrator. The system that resists growth is not a radar — it is a project liability.

Each collector subagent is a markdown prompt file Claude Code loads as a task. The design constraint is strict: each collector knows nothing about the others. It queries one API, extracts the signals that matter, and returns a standardized JSON payload. That isolation is what makes the system extend cleanly — adding a sixth source is one new collector file, not an orchestrator rewrite.

What each collector pulls:

The orchestrator is the most important piece, and the one most teams get wrong on the first attempt. Its job is not to summarize. Its job is to correlate and judge.

A blocked Jira ticket is AMBER on its own. The same feature with a PR open five days and zero reviews is RED. The blocker is not the ticket status — it is a review bottleneck stalling an entire feature. The orchestrator catches this because it sees both signals at once.

The scoring pass runs in three stages:

Here is the failure mode that kills most alert systems: thresholds get set on what feels reasonable, the system ships, nothing gets adjusted. Within two weeks the brief either cries wolf so often that leaders ignore it, or it misses a real incident because the thresholds were too relaxed.

The calibration loop is not optional. It is the feature that separates a useful radar from another notification channel.

Start intentionally too sensitive. Set every threshold at the aggressive end. PR open longer than 24 hours? AMBER. Two blocked tickets? RED. Business metric down 5% week-over-week? RED. The system should over-report in the first week. Tightening down is easy. Discovering missed signals after the fact is not.

Each RED and AMBER item carries the same four fields: source attribution, confidence percentage, temporal context, and a concrete suggested action. The leader reads the brief in 90 seconds and walks out knowing what needs attention and what the first move is.

The GREEN summary compresses to bullets on purpose. If everything is healthy, the leader does not need details — they need confirmation that the radar actually checked. A brief with no GREEN section is ambiguous: did the system find nothing, or did it fail silently?

The architecture looks clean in the diagram. Production finds the edges.

API timeouts are the most common. Jira Cloud and Google Sheets both have rate limits and occasional 5xx flakiness. A collector that hangs indefinitely blocks the orchestrator, which means the brief never lands. Fix: set a hard 15-second timeout per collector. If the timeout fires, return {"source": "jira", "source_status": "degraded", "signals": []} and continue. The orchestrator notes the degraded source in the GREEN section. Silent failure is worse than partial data.

Token budgets compound. Each collector call consumes tokens. At 2–4K input tokens per collector and five collectors running in parallel, you are spending 10–20K input tokens before the orchestrator even starts. The orchestrator prompt itself — loaded with five collector payloads — can run 8–15K tokens. Budget for 25–40K tokens per pipeline run. At Anthropic's current Sonnet pricing, that lands around $0.15–0.30 per run.^[9] If you are running twice daily, that is roughly $9–18/month. Still orders of magnitude cheaper than the engineering-leader salary time it displaces, but worth tracking rather than discovering on your cloud bill.

Rate limits hit collectors at scale. The Jira Cloud REST API enforces per-user rate limits (currently ~100 requests/10 seconds for most Cloud plans). If your collector is running complex JQL across large projects, it can hit this. Fix: paginate with maxResults=50 and add 200ms back-off between paginated requests. GitHub's GraphQL API has a separate cost-points budget (5,000 points/hour), and a complex PR query can cost 5–10 points. Watch the X-RateLimit-Remaining response header and log it in the collector payload.

Orchestrator hallucination on low-quality collector payloads. If a collector returns inconsistent JSON (missing fields, wrong types), the orchestrator can misclassify or fabricate context. Add a schema validation step inside the orchestrator prompt: "If any collector payload is missing required fields, treat it as source_status: degraded and exclude it from correlation." This is a prompt-level guard, not a code-level one, because the orchestrator is an LLM.

Confidence score drift over time. False-positive dampening only works if you log every FP. Teams that skip the false-positives.jsonl file for two weeks watch their calibration go stale. The weekly review meeting needs to be on the calendar with an owner, not left to "someone will do it when it's annoying enough."

Delivering the brief to a public channel. The brief contains operational detail about your engineering teams — what is blocked, who is not reviewing, which metrics are down. Never deliver to a public Slack channel or a shared inbox. Use a private DM, a permission-locked Google Doc, or an encrypted email. Treat the brief as production output, not a newsletter.

Once the radar works for one director, the question is whether every engineering manager can run their own. Yes — with one architectural rule.

Collectors can be shared. A single Jira collector pulling all blocked tickets is more efficient than one per manager. The orchestrator must be personalized. Each leader cares about different teams, different projects, and runs different threshold tolerances.

The cleanest cut is a profiles/ directory where each leader has a config file specifying their teams, projects, and custom thresholds. The orchestrator loads the relevant profile and filters collector output accordingly.

That structure also opens an organizational view: if every leader's radar data is logged, a CPO or CTO can run a meta-analysis across all briefs. Which teams consistently show RED? Which systems generate the most false positives? Which cross-team dependencies surface as correlated signals?

One uncomfortable finding from teams that have rolled this out at scale: some managers actively resist the brief format. Not because the data is wrong. Because scanning dashboards manually was giving them a reason to open conversations with their teams. The morning Jira ritual was also an excuse to ping a teammate, notice something off in passing, stay close to the work. Automating the scan removes that ambient contact. Worth knowing before you push it to fifteen managers at once. The fix is structural, not motivational: replace the lost contact surface with a deliberate one — a 15-minute pulse with each direct, on a schedule, owned by the leader.

The signal radar is not a complicated system. Five focused collectors, one orchestrator, a delivery channel, and a calibration loop that tightens over time. The hard part is not building it — that week is behind you by Friday. The hard part is the discipline to log false positives and adjust thresholds for the first month, even when the brief is already useful enough that skipping the review feels acceptable.

Once calibrated, the radar restructures the morning. A 90-second brief lands before standup, names what needs intervention, shows the source attribution, and offers a first move.^[4] Signals that crossed two systems overnight surface automatically. The ones that do not make the RED or AMBER threshold stay GREEN — proof the radar ran, not dead air.

Six dashboards were not observability. They were a coordination tax you paid every morning, in working memory, before the first 1:1 of the day. Pay it once, in code, and put the 45 minutes somewhere it compounds.