Reliability
Vangrd saves job timing, restores sessions, retries browser failures, and reports blocked work. See how recovery works.
Last reviewed: Oct 12, 2026
Vangrd saves settings, job definitions, and job timing. After a restart, the scheduler restores timing and checks which jobs can run. Custom workflows save their position at action and delay boundaries.
Workflow triggers and saved progressHealth checks detect failed or unresponsive browsers. Recovery uses increasing retry delays and repeated-failure limits. Vangrd saves cookies and local storage during controlled browser recycling to help restore sessions.
Check your agent and job statusThe browser host can run Chromium separately from the automation service. With this mode enabled, a service update detaches from the browser and reconnects afterward. The browser host itself must remain running.
How cloud operation worksIndependent village task chains contain ordinary errors and resource waits. Other chains can continue. Scheduler deadlines and a watchdog also detect stalled work. Browser failure still affects tasks that share that browser.
Building plans and queue checksTasks check resource-data freshness and refresh stale village state. Resource forecasts use the last scanned baseline. Shipment state updates from game responses help supply jobs account for merchants and resources in transit.
Supply links and resource reservesAttack plans save their state and send attempts. Dedicated scheduling handles attack and defense deadlines. After a restart, due work is checked again. Missed timing and stale preparation can fail a plan instead of sending it late.
Configure attack sends and arrival timesThe Status page shows jobs, runs, and problems. Resource waits and queue limits appear as waiting states. Failed jobs use retry delays. Rejected credentials require correction before that access can continue.
Read waiting states and problemsPage checks recognize supported interface layouts. Recognized failures can capture screenshots and an action timeline for diagnosis. These records help trace compatibility problems and prepare fixes.
Read compatibility fixes in the changelogOur regression tests cover restart adoption, retry delays, stalled scheduler work, village error containment, and workflow resume. Tests use controlled failures and game-page fixtures. They check expected behavior under those conditions.
These recovery mechanisms keep eligible work moving and make interruptions visible. Game actions need a valid session and working connection.
Successful send responses returned a median 374 ms after the scheduled time in our recorded sample. Sixteen of 18 successful responses returned less than 1,000 ms after the scheduled time.
Internal measurement: one account, 19 attempts, 18 completed tasks, and one failure before the final send handler. The observation window ran from October 10, 2026 at 05:45 UTC to October 11, 2026 at 05:45 UTC, excluding the endpoint.
We paired retained planned-send task starts with their recorded outcomes. Timing measures when the client observed an HTTP 302 response after reading its body, relative to the planned send time. It includes network and response processing time. It does not measure request dispatch, game acceptance, or troop arrival.
The timing sample includes the 18 successful responses. All 19 observed attempts count toward the outcome total. Retained records cannot establish every scheduled intention or continuous collection. This single-account sample does not establish a fleet-wide timing or recovery rate.
Dated product notes show specific fixes, including critical sends after restart, resource sending, and building prerequisites. Each note has a permanent link.