Skip to main content
Talon has a second kind of work besides investigating alerts: ops jobs, scheduled checks that look after the stack and tell the SOC what needs attention. Each job gathers its numbers with read-only calls and decides in code what counts as a finding; one model call per run then ranks the findings and explains why each matters and what to do. The Ops tab of the AI Analyst page shows the findings, and the Talon flags something in the stack notification trigger sends new ones to your SOC’s own channels.
Ops findings are for the SOC only. Customers never see them: not in the customer portal, and not on customer notification routes. The Ops tab appears only with the Talon v2 setting on, and needs a talon-analyst release with the ops API.

​
What the jobs check

Each finding is about one subject (an agent, or a source and its index pattern) and stays one finding across runs: Talon updates it while it lasts and resolves it once the subject is measured healthy again. A run that couldn’t measure something resolves nothing, so an outage never makes problems disappear. What is code and what is the model. The severity, title, evidence (numbers, ids and times, never log text) and any artifact are written by the job’s code. Why it matters and what to do are the model’s explanation; when there isn’t one (the model’s budget was spent, say) the recommendation is the job’s own fixed hint. CoPilot shows the model’s text as plain text, never as Markdown or HTML.

​
The Ops tab

AI Analyst → Ops, for admins, analysts and responders, like the Memory tab.
  • Findings. Filter by job, customer, status (open by default), severity and, for admins, platform findings. Each row shows the severity, title, customer, job, when it was first and last seen and its status. Load more pages through older ones.
  • A finding’s detail opens in a side drawer: the evidence as a list of fields, any artifact in a copyable code block, and Talon’s explanation and recommendation as plain text.
  • Actions on a finding, each recorded in CoPilot’s audit log (talon_ops.acknowledge, talon_ops.mute, talon_ops.reopen) and in Talon’s, with you as the actor:
    • Acknowledge: you’ve seen it; it stops being open.
    • Mute until a date (at most 90 days ahead): it stays quiet until then, and is open again afterwards if it is still true.
    • Reopen an acknowledged or muted finding. A resolved finding can’t be reopened by hand: it opens again when a run finds it again. An acknowledged finding whose severity rises is open again.
  • Jobs. Each job with its schedule, its last run (status, the counts of new, updated and resolved findings, when) and its next run. Admins have Run now for an enabled job (talon_ops.run in the audit log).
Who sees what. You see findings for the customers you are assigned to; admins see every customer. Platform findings (about the stack as a whole, not one customer) are for admins only. CoPilot checks every finding’s stored customer on every request, before showing or acting on it. None of today’s jobs make platform findings. When no job is enabled in Talon, the tab says Ops jobs are off in Talon and how to turn them on (below).

​
Notifications

Create an internal route (Notifications → Internal Routes) with the trigger Talon flags something in the stack. CoPilot asks Talon for new findings every 3 minutes and sends each one each time it becomes news: when it is new, when it comes back after resolving, when its severity rises and when a mute on it expires. A finding that stays the same is not sent again, and a severity that falls is not sent. The route’s minimum severity applies (Talon’s info, low, medium and high are CoPilot’s Informational, Low, Medium and High).
  • The default message names the finding, the job, the customer, its status and when it was first and last seen, with a link to the Ops tab (set COPILOT_URL for the link).
  • A webhook gets the finding as data in an ops_finding object: see The ops_finding block.
  • A template can use {{ context.ops_finding }}, including Talon’s why and recommendation. Every string from Talon (the model’s text, but also titles and the host names and OS strings endpoints report) is escaped in HTML and Markdown templates and everywhere on Teams, so a link or image in it shows as text.
A finding is recorded as notified once CoPilot has queued it, whatever the routes do with it: with no route, every route disabled, or every route’s minimum severity above it, it is never sent later, even once you create, enable or lower a route. So your first route doesn’t receive every old finding at once; the Ops tab still lists them. Several CoPilot backends can run side by side: one takes each round (a database lock), and a finding already queued for the same moment is never queued again. To read the findings, the job titles and to record what it sent, CoPilot talks to Talon as its own service identity (copilot-ops-poller, every customer); only an admin can run, pause, reschedule or delete that job in the scheduler.

​
Turning the jobs on

The jobs run in talon-analyst, and are off until you enable them there. In talon-analyst’s .env, on every api and worker container:
silent_log_sources also needs Talon’s indexer connection (TALON_MCP_INDEXER_URL), and the jobs need a worker running. Restart Talon after the change. Optional settings (see talon-analyst’s INSTALL.md): In CoPilot, turn on the Talon v2 setting, then open AI Analyst → Ops. The health dashboard’s Ops jobs row warns when a job’s last run failed or was skipped; the Jobs panel shows its error.