Monitoring, Logging, and Troubleshooting
Where the evidence lives
Alteryx Server produces several log streams: the service logs (controller/worker engine and service events), Gallery/web logs, MongoDB logs, and per-workflow run logs surfaced in the Gallery results. Know which log answers which question: a failed run's engine messages are in the run log; a worker that won't register is in the service log; a login failure is in the Gallery/auth log.
Monitoring surfaces
The Gallery has an Admin area showing worker status, queue depth, and running jobs. System health checks confirm controller/worker/MongoDB connectivity. Performance issues often trace to worker saturation, MongoDB latency, or disk space on the data directory.
Troubleshooting method
Work from symptom to layer. Job stuck queued → worker availability/queue/concurrency. Job fails immediately → workflow dependency, credential, or engine error in the run log. Gallery slow or 500s → web tier, MongoDB, or disk. Auth failures → identity provider/SAML config or account provisioning. Always check timestamps and correlate across logs.
Traps
Questions assume the Gallery shows full engine stack traces (it shows run logs, but deep diagnostics live in service logs). Another trap: assuming a green health check means workflows will run - health checks connectivity, not workflow correctness. Also watch for ignoring disk space; MongoDB and the data directory filling up cause broad, misleading failures.
Worked example
Users report intermittent failures at 2 a.m. Check the run logs for the failed jobs, correlate with service logs at 2 a.m., and look at worker status and disk usage. If a backup job runs at 2 a.m. and saturates disk I/O, that correlation explains the failures - a monitoring win, not a workflow bug.
Rule of thumb
Match the symptom to the layer, then read the log that owns that layer. Correlate by timestamp before changing anything.