Incident and Remediation Workflows

An incident does not end when someone opens a ticket. The useful handoff is a controlled path from signal to investigation, change, approval, and a record of what happened.

Start from the signal you already have

A webhook trigger can accept an inbound event with HMAC validation. An agent-signal trigger can start a pipeline from another pipeline's output. The input can be checked against a schema before an agent receives it, so the workflow can require the incident reference, affected service, and available evidence that your process needs.

Farna Control does not ship an incident detector or replace an incident-management system. Your monitoring and operations tools remain the source of the signal. The connected workflow governs the response steps that you choose to run.

Separate investigation from change

A pipeline can collect context, ask an agent to propose a remediation, and use repository or issue connectors to prepare the work. Evaluation gates can check the output, and a human-only approval gate can stop the workflow before a production-affecting action. Rejection can route the run back to investigation or close the workflow, depending on the graph.

Every step that runs through Farna Control contributes to the run snapshot and audit record. The record shows the trigger, the agent output, the checks, the approval decision, and the final artifact.

Connector-dependent operations

The actions available after the signal depend on the connector instances and credentials in your deployment. Repository writes, issue updates, notifications, deployment actions, and CI observation are separate capabilities. CI-runner dispatch from a pipeline node remains in development, so a workflow should not describe starting an external CI job as a current Farna Control capability.

Where to go next

• Security Remediation Workflows: a security-specific response path
• What Farna Control Does With GitHub: repository and issue actions
• Triggers: webhook and agent-signal entry points