Fiabilité
Vangrd sauvegarde les horaires des tâches, restaure les sessions, relance les navigateurs défaillants et signale les tâches bloquées. Découvrez comment fonctionne la récupération.
Dernière vérification : 12 oct. 2026
Vangrd sauvegarde les paramètres, les définitions et les horaires des tâches. Après un redémarrage, le planificateur restaure les horaires et vérifie les tâches exécutables. Les procédures personnalisées sauvegardent leur position aux limites des actions et des délais.
Déclencheurs et progression sauvegardée des procéduresLes contrôles de santé détectent les navigateurs défaillants ou bloqués. La récupération utilise des délais de nouvelle tentative croissants et des limites d'échecs répétés. Vangrd sauvegarde cookies et stockage local pendant les redémarrages contrôlés du navigateur pour restaurer les sessions.
Vérifier l'état de votre agent et des tâchesL'hôte de navigateur peut exécuter Chromium séparément du service d'automatisation. Dans ce mode, une mise à jour du service se déconnecte du navigateur puis s'y reconnecte. L'hôte de navigateur doit rester actif.
Comment fonctionne le cloudLes chaînes de tâches indépendantes des villages contiennent les erreurs ordinaires et les attentes de ressources. Les autres chaînes peuvent continuer. Les échéances du planificateur et un dispositif de surveillance détectent aussi les blocages. Une panne du navigateur affecte toutefois les tâches qui le partagent.
Plans de construction et contrôles des filesLes tâches vérifient la fraîcheur des ressources et actualisent l'état périmé des villages. Les prévisions utilisent la dernière base observée. Les mises à jour d'envoi issues des réponses du jeu aident les tâches d'approvisionnement à tenir compte des marchands et ressources en transit.
Liens d'approvisionnement et réserves de ressourcesLes plans d'attaque enregistrent leur état et les tentatives d'envoi. Une planification dédiée gère les échéances d'attaque et de défense. Après un redémarrage, les tâches dues sont revérifiées. Un délai manqué ou une préparation périmée peut faire échouer le plan au lieu de l'envoyer en retard.
Configurer les envois d'attaque et les heures d'arrivéeLa page État affiche les tâches, les exécutions et les problèmes. Les besoins de ressources et les limites de file apparaissent comme des états d'attente. Les tâches échouées utilisent des délais de nouvelle tentative. Les identifiants rejetés doivent être corrigés avant la reprise de cet accès.
Lire les états d'attente et les problèmesLes contrôles de page reconnaissent les dispositions d'interface prises en charge. Les échecs reconnus peuvent produire des captures d'écran et une chronologie des actions pour le diagnostic. Ces données aident à identifier les problèmes de compatibilité et à préparer les corrections.
Lire les corrections de compatibilité dans le journal des modificationsNos tests de régression couvrent la reprise après redémarrage, les délais de nouvelle tentative, les blocages du planificateur, le confinement des erreurs par village et la reprise des procédures. Les tests utilisent des pannes contrôlées et des pages de jeu simulées. Ils vérifient le comportement attendu dans ces conditions.
Ces mécanismes de récupération maintiennent les tâches possibles et rendent les interruptions visibles. Les actions de jeu nécessitent une session valide et une connexion fonctionnelle.
Dans notre échantillon, les réponses d'envoi réussies sont revenues avec un retard médian de 374 ms sur l'heure prévue. Seize des 18 réponses réussies sont revenues moins de 1,000 ms après cette heure.
Mesure interne : un compte, 19 tentatives, 18 tâches terminées et un échec avant le gestionnaire d'envoi final. La période d'observation va du 10 octobre 2026 à 05:45 UTC au 11 octobre 2026 à 05:45 UTC, borne finale exclue.
Nous avons associé les débuts conservés des tâches d'envoi planifiées à leurs résultats enregistrés. Le timing mesure quand le client a observé une réponse HTTP 302 après lecture de son corps, par rapport à l'envoi prévu. Il inclut le réseau et le traitement de la réponse. Il ne mesure ni l'émission de la requête, ni l'acceptation par le jeu, ni l'arrivée des troupes.
L'échantillon de timing comprend les 18 réponses réussies. Les 19 tentatives observées comptent dans le total des résultats. Les données conservées ne permettent pas d'établir toutes les intentions planifiées ni une collecte continue. Cet échantillon d'un compte n'établit pas un taux de timing ou de récupération pour l'ensemble des agents.
Les notes produit datées décrivent des corrections précises, dont les envois critiques après redémarrage, les envois de ressources et les prérequis de construction. Chaque note possède un lien permanent.