Administration

Diagnostiquer l’état avant de relancer l’action

Un diagnostic sûr commence par préserver portée, état, horaires, couverture et code support. Suivez ensuite l’opération du produit source vers Activity et la preuve Billing sans transformer une ligne absente en fausse conclusion.

Si une opération paraît bloquée ou incomplète, utilisez le dépannage dans Activity pour conserver son statut et les éléments utiles avant de réessayer.

La portée d’abord

Organisation, workspace, ressource, marché, filtres et dates peuvent produire une vue vide valide.

L’état plutôt que le spinner

Accepté, en file, en cours, persisté et publié ne sont pas le même jalon.

Preuve sûre

Codes support et compteurs bornés reproduisent un problème sans exposer erreur interne ou secret.

Conservez l’état avant de tenter une correction

Notez organisation, workspace, projet, domaine, marché, langue et URL.

Copiez état, horaires, compteurs, code support et texte exact de l’erreur.

Consignez filtres, recherche, fenêtre, sélection et mentions comme borné, partiel, échantillonné ou propre au viewer.

Identifiez si vous regardez un formulaire de configuration, un run source, un dashboard dérivé, une ligne Activity ou un enregistrement Billing.

Rechargez, relancez, changez de portée ou créez un autre run seulement ensuite.

Écartez d’abord une mauvaise portée

Beaucoup de vues vides ou surprenantes sont des résultats valides pour la mauvaise organisation, le mauvais workspace, projet, domaine, pays, langue, liste, appareil, date ou vue enregistrée. Effacez recherche et filtres, mais lisez aussi les libellés de portée.

Ne déplacez pas de données et n’élargissez pas les droits avant d’avoir reproduit le problème dans le périmètre voulu.

Chargement, vide et ancien sont trois états différents

État	À vérifier
Chargement	Requête toujours active, existence du run source et démarrage réel du worker.
Vide	Portée, filtres, prérequis, couverture source et existence d’un enregistrement éligible.
Ancien	Date source, dernier run réussi, historique du planning, baseline et publication d’un run plus récent.

Utilisez Activity comme index puis diagnostiquez dans le produit source

Activity peut relier une opération prise en charge à son état normalisé, sa portée, ses compteurs, son initiateur, son code support, sa destination et sa preuve Billing. Dashboard de 30 ou 90 jours, calendrier de 365 jours, lectures source et timeline de 100 lignes sont bornés. Une ligne absente ne prouve pas qu’aucune action produit n’a eu lieu.

Activity ne peut ni annuler, reprendre, relancer, réparer ou publier un run. Suivez la destination et inspectez l’état et la sortie du produit propriétaire avant d’agir.

Liste d'activité avec opérations réussies, enrichissement SERP, run de suivi et requête SERP échouée. — Lorsque les données semblent fausses, Activity montre souvent si une opération s'est terminée, a échoué ou a traité moins de lignes.

Une requête enregistrée ne prouve pas le travail en arrière-plan

Pour un travail en file ou en cours, séparez acceptation, dispatch, démarrage du worker, réponse fournisseur, persistance et publication. Une réponse de soumission réussie ne prouve que le contrat qu’elle décrit.

Avant de relancer, cherchez un run déjà actif, une réservation détenue, une sortie partiellement persistée et le chemin de récupération proposé par le produit. Des relances répétées peuvent dupliquer le coût et brouiller la preuve.

Les résultats partiels, bornés ou échantillonnés restent utiles avec leurs limites

Lisez la mention de couverture ou de limite avant de comparer des nombres.
Ne traitez pas les lignes hors de la page retournée comme des zéros.
Comparez des runs seulement avec portée, version de règle, marché, appareil et couverture compatibles.
Un export peut ne contenir que le sous-ensemble chargé ou retourné.
Une dépense marquée comme au moins n’est pas un total financier complet.

Données cachées, action refusée et solde insuffisant appellent des réponses différentes

Un contrôle absent peut venir d’une capacité, d’un rôle, d’une attribution de workspace ou projet, du plan ou d’un feature gate. Demandez à un admin de vérifier la capacité exacte sur la ressource plutôt que d’accorder un rôle large au hasard.

Des données Billing cachées ne valent pas zéro. Si une opération mesurée est bloquée, contrôlez séparément solde utilisable, estimation ou réservation, run source et historique de paiement.

Si le solde ou les droits de facturation empêchent le démarrage, vérifiez la facturation et l'utilisation avant de répéter l'opération.

Pour import et export, prouvez l’ensemble de lignes

Gardez le fichier original et notez séparateur, encodage, en-têtes, marché et nombre de lignes.

Testez un petit lot représentatif avant un import important.

Inspectez lignes rejetées, dupliquées, vides ou normalisées au lieu de compter seulement la table finale.

Avant export, notez filtres, recherche, sélection, colonnes, tri, pages chargées et couverture.

Ouvrez le fichier exporté et comparez quelques enregistrements connus avec la vue source.

Relancez seulement si l’état actuel le justifie

État observé	Suite plus sûre
Erreur de validation ou prérequis	Corrigez saisie, accès, vérification, marché ou configuration avant une nouvelle opération.
En file ou en cours	Vérifiez dispatch et propriété du worker; évitez un run dupliqué.
Partiel	Conservez la sortie utile, identifiez le manque et suivez le parcours de reprise documenté.
Échoué ou annulé	Lisez code support, disposition Billing et contrôles de récupération du produit source.
Réussi mais résultat suspect	Auditez portée, couverture, date source, transformations et publication avant de relancer.

Transmettez un dossier reproductible et sûr

Organisation, workspace, route produit, ressource et fuseau du navigateur.
Action tentée, résultat attendu, résultat réel et reproductibilité.
Run source ou identité visible, horaires, état, compteurs et code support.
Couverture, limite, filtres, marché, langue, appareil et date.
État Billing ou référence fournisseur si utile, sans jeton, secret, carte ou donnée client privée.