Scheduling Failures After a Database Host Migration
After migrating the Alteryx Server MongoDB and the Controller's persistence to a new host, the team finds that scheduled workflows no longer fire. Manual runs from the Gallery succeed. The Scheduler shows schedules as 'active' but no runs appear in history at the expected times. The migration changed the MongoDB connection string in the System Settings, and the team also rotated the service account password for the Controller service. Workers still show as connected in the Worker list. The change happened on a Friday; the first missed runs were Saturday 02:00.
1. What is the most likely cause, and how would you confirm it?
Read the worked answer
The symptom pattern (manual runs work, schedules show active but never fire, Workers connected) points at the Scheduler service rather than the Workers or the workflows themselves. The Scheduler is a separate Alteryx service on the Controller; if it is not running, crashed after the change, or cannot reach the persistence layer, schedules will look active in the UI but never enqueue. The two changes (MongoDB connection string and Controller service account password) are the prime suspects: a wrong connection string or a service account that can no longer authenticate to MongoDB would prevent the Scheduler from reading/writing schedule state. Confirm by checking the Scheduler service status on the Controller, reviewing the Scheduler and Controller logs around Saturday 02:00 for connection or authentication errors, and verifying the connection string and credentials from the Controller host (e.g., test connectivity to the MongoDB host on its port). Also confirm the Workers' connection to the Controller is genuinely healthy, not just displayed as connected from cached state.
2. What is the correct remediation order, and what should be validated before declaring the incident closed?
Read the worked answer
Remediation order: (1) fix the underlying credential/connection problem first (correct the MongoDB connection string and update the service account password everywhere it is stored, including the Windows service logon and any Alteryx configuration that holds it); (2) restart the affected services in the right order (persistence/MongoDB reachable, then Controller/Scheduler, then Workers) so state is consistent; (3) verify the Scheduler is running and can read schedules. Before closing: confirm a test schedule fires at its next interval and appears in run history, confirm previously missed schedules are either caught up or intentionally skipped (not silently lost), and check that no duplicate runs were enqueued by restarts. Also document the credential rotation so the next password change updates all components, since this failure mode will recur otherwise.