Troubleshooting and Operations
This domain tests whether you can localize a failure to configuration, content, connectivity, or platform using logs and evidence rather than guesswork.
Where to look
- The War Room shows each task's command, arguments, result, and error. It is the first place to look for a failed playbook.
- Server logs are downloadable from the troubleshooting settings; raise the log level and add debug statements when the War Room is not detailed enough.
- The integration instance's test button validates credentials and connectivity independently of any playbook.
- The local mock lets you run integration code outside the server, so packaging and logic bugs are separated from server problems.
Common failures
- Nothing fetched: check the fetch query, the first-fetch window, the stored last-run state, and whether the classifier rejected the incidents.
- Command not found: the instance is disabled, unconfigured, or does not implement that command.
- Task hangs: the underlying call is waiting on a timeout; the container image may be failing to pull, or the worker pool may be saturated.
- Search looks stale: Elasticsearch indexing lags behind writes; the data is present even when results are delayed.
Worked example
A playbook sits at running with no error. Reasoning: open the task in the War Room and read the last command; if the integration call is still waiting, confirm connectivity and run the instance test, then check whether the image pulled and whether workers are queued. Only after those are eliminated is it a code bug.
Traps
Debugging from the canvas without reading task output, changing an incident type and expecting open incidents to change, and reinstalling a pack instead of fixing the failing field or version constraint.