Skip to content
TriageTriage
Esc
↑↓navigate↵open⌘Jpreview
On this page

Commands

Every triage command, argument and flag, generated from the CLI's help.

Each command has its own page with its help, as triage <command> --help prints it.

Command Alias
collect None
issues None
upload None
serve None
work None
hosts None
admins None
workers None
decide None
suggest None
label None
resolve None
mute None
reopen None
agreement None

Global flags

DESCRIPTION
  Capture crashes and errors from your machines, decide which are worth fixing, and suggest fixes

USAGE
  triage <subcommand> [flags]

GLOBAL FLAGS
  --help, -h                                                          Show help information
  --version, -v                                                       Show version information
  --wizard                                                            Start wizard mode for a command
  --completions <bash|zsh|fish|sh>                                    Print shell completion script (choices: bash, zsh, fish, sh)
  --log-level <all|trace|debug|info|warn|warning|error|fatal|none>    Sets the minimum log level (choices: all, trace, debug, info, warn, warning, error, fatal, none)

SUBCOMMANDS
  collect      Collect crashes, failures and errors from this machine's journal since the last run
  issues       List issues, most recently seen first
  upload       Send collected events to the server at $TRIAGE_SERVER, authenticating with $TRIAGE_TOKEN
  serve        Run the triage server over HTTP, which collects events from enrolled hosts. Use a reverse proxy or Cloudflare for HTTPS
  work         Decide on issues and suggest fixes for the server at $TRIAGE_SERVER, authenticating with $TRIAGE_WORKER_TOKEN, within the server's daily limits. Needs --decide, --suggest or both
  hosts        Manage the hosts that can send events
  admins       Manage the admins that can read issues and manage tokens
  workers      Manage the workers that can decide on issues and suggest fixes for this server
  decide       Ask a decision model whether the server's new issues are worth fixing, storing the answers without acting on them
  suggest      Ask a language model how to fix some of the server's issues, from their redacted events only, and store its suggestions
  label        Label one of the server's issues by hand, to measure decision models against
  resolve      Resolve issues once they're fixed. One that happens again opens as regressed, and is decided on again
  mute         Mute issues, so they're never decided on or suggested fixes for, however often they happen
  reopen       Reopen resolved or muted issues
  agreement    Compare each decision model with the hand labels: how often it's sure enough to act on, and how often it's right when it is

Last updated on