What an output does
An output is a destination for a run’s results. When a run completes, Console dispatches every output you’ve configured. Outputs are optional — without one, a run still records its findings in Console; it just doesn’t push them anywhere. Add them from the Output section of the workflow editor. You can add one of each destination type, but not two of the same kind. The pull request comment and the merge gate act on the pull request that triggered the run, so they only do something for runs a pull request started. On a manual run they’re recorded as skipped. Post to Slack posts to a channel you choose, so it runs for every completed run, including manual and scheduled ones.Comment on triggering pull request
Posts the run’s findings as review comments on the pull or merge request that fired the workflow, with links back to the full finding in Console. This works for both GitHub pull requests and GitLab merge requests. Use it when you want the agent’s results to show up where reviewers already are, without changing whether the pull request can merge.Gate merging on security review
Adds a required check to the pull request that blocks merging until the security review passes or a human signs off. This is the output to use when you want the workflow to have teeth.The check
The check is named:How the gate decides
The gate fails closed by design. A workflow whose agents don’t report a gate verdict will block every
pull request pending human review, rather than waving them through.
For the gate to pass on its own, your chain needs an agent that records a gate verdict. If none does,
the gate still works — it just always routes to human approval instead of ever passing automatically.
Human approval
Approving the pull request releases a gate that’s waiting on human review, and the check flips to passing. This also works retroactively: if someone approved the pull request before the gate finished posting, Console resolves the gate as approved rather than leaving an already-approved pull request stuck. By default, later requesting changes on a pull request whose gate was already approved does not re-block it.Requiring the check in GitHub
Adding the output makes the check report. It doesn’t make it required — that’s a GitHub branch protection setting you control:- In GitHub, go to Settings → Branches (or Rules → Rulesets) for the repository.
- Edit the rule protecting your target branch, e.g.
main. - Enable Require status checks to pass before merging.
- Search for
Console / <your workflow name>and add it.
GitLab
Merge blocking isn’t supported for GitLab merge requests yet. A merge gate on a GitLab run is recorded as skipped. Use Comment on triggering pull request for GitLab in the meantime.Post to Slack
Posts one message summarizing the run to a Slack channel: the workflow’s name and the run’s summary, counts by severity, up to five top findings with links, and an Open run button. If the run failed, the message says so. It needs the Slack app installed for your organization. When you add it, pick the Workspace and the Channel, then click Add output. Only public channels are listed. Console checks that the workspace is still connected to your organization when you save. The message is posted as Amplify Console. The bot posts to any public channel without being invited. If delivery fails, for example because the channel was archived, the output shows Failed on the run’s detail page.Delivering anywhere else
The other outputs go to the triggering pull request or to Slack. To put results in Jira, Linear, Confluence, Notion, Asana, or Google Docs, or to write your own Slack message, add a final step to the chain instead: an agent that consumes the run’s findings and posts them through that app’s integration tools. Unlike the pull request outputs, such a step runs on manual runs too. Two ready-made shapes — one summary message per run, and one issue per finding — are in adding a delivery step.Checking delivery
Every run’s detail page lists the outputs it dispatched and whether each was delivered:
If an output shows Failed, check that the Console GitHub App is still installed for the repository
and has permission to write checks and pull request comments.
Next steps
Run and monitor
Fire a run and confirm your outputs delivered.
Configure triggers
Outputs need a pull-request run to act on.