Wiederkehrende Messungen planen, ohne fällig mit erledigt zu verwechseln

Verstehe einen Zeitplan als wiederkehrenden Messvertrag

Ein Position-Tracking-Zeitplan speichert, was erneut gemessen werden soll und wem der Auftrag gehört: Workspace, feste Keyword-Auswahl oder aktuelle Liste, Datenart, Rhythmus, SERP-Kontext oder Keyword-Datenpakete, optionales Budgetlimit, Status und nächste Fälligkeit. Er konfiguriert künftige Claims. Er verspricht weder einen Provider-Aufruf genau zum Fälligkeitszeitpunkt noch vollständige Daten für jede angeforderte Zeile.

Die Zeitplanansicht kann listenbasierte SERP- und Keyword-Datenaufträge für die gewählte Liste, feste Keyword-Auswahlen auf Workspace-Ebene und eine begrenzte Übersicht aller Aufträge zeigen. Das aktuelle Standardlimit für Ressource und Anzeige liegt bei 30 aktiven oder pausierten Zeitplänen je Workspace. Der wirksame Tarif oder eine Sicherheitsregel kann es weiter senken. Archivierte Zeitpläne erscheinen nicht in den üblichen Listen.

Unterscheide feste von zur Laufzeit aufgelöster Mitgliedschaft

Ein direkter Zeitplan speichert eine normalisierte und deduplizierte Keyword-Menge. Er gilt nur für SERP-Daten und unterstützt standardmäßig bis zu 200 Keywords. Seine Mitgliedschaft ändert sich nur im eigenen Auswahl-Editor, der keine leere Menge speichert. Ein listenbasierter Zeitplan speichert dagegen die Listen-ID. Jeder Lauf löst die aktuelle Mitgliedschaft neu auf. Hinzugefügte oder entfernte Keywords verändern damit die nächste Erfassung, aber nicht die Zähler vergangener Läufe.

Die aktuelle Obergrenze je Lauf liegt bei 500 Keywords. Anlage und Kostenschätzung lehnen eine zu große Liste ab. Der Dispatcher prüft die aktuelle Liste vor jedem Lauf erneut. Wächst eine zuvor gültige Liste über das wirksame Limit, kann der Zeitplan vor dem Dispatch scheitern. Der Lauf hält den Mitgliedschaftsfehler fest, statt unbemerkt nur die ersten 500 Zeilen zu verwenden.

• Ein direkter Zeitplan behält seine feste Kohorte, bis ein Mensch sie bearbeitet.
• Ein Zeitplan für die gesamte Liste folgt deren aktueller Mitgliedschaft. Kosten und Vergleichbarkeit können sich dadurch ändern.
• Eine Teilmenge aus dem Einrichtungsdialog wird als feste direkte Auswahl gespeichert, nicht als dynamischer Ausschnitt der Liste.
• Die angeforderte Anzahl eines Laufs ist der unveränderliche Beleg für die bei diesem Claim aufgelöste Mitgliedschaft.

Stimme Datenart und Rhythmus auf die Entscheidung ab

SERP-Zeitpläne können täglich, wöchentlich, alle zwei Wochen oder monatlich erfassen. Keyword-Daten lassen sich monatlich oder quartalsweise aktualisieren und benötigen mindestens ein Paket. Beim Bearbeiten bleibt die Datenart gesperrt. Wer von SERP zu Keyword-Daten oder in die andere Richtung wechseln will, legt einen eigenen Zeitplan an. Wähle den Rhythmus danach, wann jemand die Evidenz tatsächlich prüft und nutzt, nicht danach, welcher kurze Abstand am vollständigsten wirkt.

Die Monatsprojektion rechnet mit Durchschnittswerten: 365 geteilt durch 12 für täglich, 52 geteilt durch 12 für wöchentlich, 26 geteilt durch 12 für alle zwei Wochen, eins für monatlich und ein Drittel für quartalsweise. Reale Kalendermonate haben unterschiedlich viele Tage und Wochenereignisse. Monatliche und quartalsweise Fälligkeiten rechnen in UTC-Kalendermonaten und begrenzen unmögliche Daten. Aus dem 31. Januar wird im Februar beispielsweise dessen letzter Tag.

Halte Tiefe, Gerät, Standort und Sprache am Lauf

Ein SERP-Zeitplan braucht Top-10- oder Top-100-Tiefe, einen positiven Standortcode, einen gültigen Sprachcode und mindestens Desktop oder Mobil. Beide Geräte erzeugen eine logische Laufgruppe mit zwei Kindläufen, zwei Reservierungen und zwei kontextspezifischen Ergebnismengen. Die Zeitplanzeile kann angeforderte und erfasste Werte zusammenfassen, während das Laufprotokoll die Kindzeilen einzeln zeigt. Eine verdoppelte Anforderungszahl kann deshalb zwei Geräte bedeuten, nicht doppelte Keywords in einem Request.

Top 10 kann nicht belegen, ob eine fehlende Domain auf Position 11 oder 100 steht. Top 100 kauft eine tiefere Beobachtung und kostet anders. Standort und Sprache beschreiben den Erfassungsauftrag. Sie übersetzen keine Keywords und machen Märkte nicht austauschbar. Gerät, Tiefe, Standort, Sprache und Mitgliedschaft müssen stabil bleiben, wenn die Zeitreihe einen Vorher-nachher-Vergleich tragen soll.

Kenne editierbare Felder und den Duplikatschlüssel

Bei listenbasierten Zeitplänen vergleicht der Duplikatschutz Liste, Datenart und Rhythmus. Für SERP kommen Gerätemenge, Standort und Sprache hinzu. Tiefe, Paketauswahl und Budgetlimit gehören nicht zu diesem Schlüssel. Zwei laufende Zeitpläne derselben Liste können sich daher nicht nur durch Top 10 gegenüber Top 100 oder nur durch Keyword-Datenpakete unterscheiden, solange der übrige Schlüssel gleich bleibt. Archivierte Zeilen kollidieren nicht mit einem neuen Zeitplan.

Bearbeitbar sind Rhythmus, SERP-Tiefe, Kontext, Geräte, Keyword-Datenpakete und Budgetlimit. Datenart und Listenbindung bleiben fest. Ein direkter Zeitplan kann seine Keywords im separaten Editor innerhalb der aktuellen Grenzen für Anzahl, Gesamtzeichen, Auswahl und Lauf ändern. Ein neuer Rhythmus berechnet die nächste Fälligkeit ab dem Bearbeitungszeitpunkt neu. Andere Änderungen schreiben abgeschlossene Läufe und deren Anforderungszahlen nicht um.

• Eine Bearbeitung verändert künftige Claims, nicht historische Snapshots oder abgerechnete Laufzeilen.
• Für Mobil duplizieren füllt einen neuen mobilen SERP-Zeitplan vor. Die Quellzeile bleibt unverändert.
• Eine Duplikatwarnung ist eine Zulassungsregel, kein Beleg für identische Berichtsverläufe.
• Muss sich der Kontext ändern, obwohl Vergleichbarkeit wichtig ist, beende die alte Reihe und benenne den neuen Vertrag eindeutig.

Lies die Vorschau als Zulassungsschätzung

Die Einrichtung bepreist die in diesem Moment bekannte Mitgliedschaft. Sie zeigt geschätzte Kosten je Lauf, durchschnittliche Läufe pro Monat, aufgelöste Keyword-Anzahl, einen angezeigten Durchschnitt je Keyword, geschätzte Monatskosten, aktuell ausgebbare Organisationsbalance und die Balance nach einem geschätzten Lauf. Die ausgebbare Balance zieht aktive Reservierungen bereits ab. Der Keyword-Wert teilt und rundet die Laufschätzung für die Anzeige. Er ist keine Preisliste des Providers.

Der SERP-Preis hängt von Keyword-Anzahl, Top 10 oder Top 100, Warteschlange und Geräteanzahl ab. Bei Keyword-Daten zählen Anzahl und Pakete. Die Monatsschätzung multipliziert das Standardangebot je Lauf mit der durchschnittlichen Frequenz und rundet auf Cent auf. Nicht enthalten sind einzelne Prioritätsläufe, späteres Listenwachstum, künftige Preisänderungen, ein neuer bezahlter Claim nach einem Retry oder andere Ausgaben aus derselben Organisationsbalance.

Trenne Zeitplanlimit und Organisationsbalance

Das optionale Monatslimit gehört zu genau einem Zeitplan und beträgt aktuell mindestens 5 EUR. Unbegrenzt bedeutet, dass dieses zeitplanbezogene Limit fehlt. Es bedeutet nie unbegrenzte Organisationsbalance. Vor einem Claim summiert Crawl Foundry die abgerechneten Kosten und noch aktiven Reservierungen dieses Zeitplans seit Beginn des aktuellen UTC-Monats. Manuelle, wiederkehrende, reguläre und priorisierte Läufe sowie alle Gerätezeilen greifen auf dasselbe Zeitplan-Ledger zu.

Würde die nächste vollständige Laufgruppe das Limit überschreiten, wird nichts dispatcht. Anschließend reserviert die Balanceprüfung vor dem Worker-Start den Gesamtbetrag für alle Geräte. Scheitert eine spätere Gerätereservierung, werden frühere Reservierungen und vorläufige Laufzeilen dieses Claims zurückgerollt. Ein Zeitplan mit zwei Geräten startet so nicht nur ein Gerät, weil während der Zulassung das Guthaben endet.

Blockaden durch Budgetlimit und zu geringe Balance verwenden beide den Laufstatus `skipped_balance`, aber unterschiedliche Fehlercodes. Jeder Fall erhöht den Zähler aufeinanderfolgender Blockaden. Nach zwei Fällen wechselt der Zeitplan zu `paused_balance`; für den Owner kann eine Pausenmail eingeplant werden. Eine erfolgreiche oder partielle abgeschlossene Gruppe setzt den Fehlerzähler zurück. Mehr Guthaben oder ein höheres Limit reaktivieren einen pausierten Zeitplan nicht automatisch.

Prüfe Organisationsabrechnung und verfügbare Balance getrennt von der Kostengrenze des einzelnen Zeitplans.

Ein manueller Lauf ist ein bezahlter Claim, kein harmloser Refresh

Jetzt ausführen nutzt dieselbe Standardwarteschlange wie wiederkehrende SERP-Läufe. Ein SERP-Zeitplan kann zusätzlich Schnell messen anbieten. Dieser einzelne Lauf nutzt eine separat bepreiste Prioritätswarteschlange. Für Keyword-Daten gibt es keine Prioritätsoption. Beide Wege lösen die aktuelle Mitgliedschaft auf, prüfen das Monatslimit, reservieren Balance, schreiben Dispatch-Zeilen und senden anschließend Worker-Ereignisse. Das bloße Öffnen eines Zeitplans oder Berichts tut nichts davon.

Ein angenommener manueller Claim setzt den nächsten Rhythmusanker auf seinen Startzeitpunkt. Er ist keine zusätzliche Beobachtung, die den Kalender unberührt lässt. Jetzt ausführen kann auch nichts starten, wenn der Zeitplan pausiert oder archiviert ist, noch ein Lauf aktiv ist, Balance fehlt oder das Limit erreicht wurde. Die Aktion in der Zeitplanliste meldet diese Gründe und öffnet das Laufprotokoll. Eine HTTP-200-Antwort allein belegt keinen Worker-Start.

Beim Anlegen speichert Crawl Foundry zuerst den Zeitplan und ruft danach dieselbe Route für den ersten Basislauf auf. Die Anlage kann gelingen, obwohl dieser direkte Request übersprungen wird oder scheitert. Der aktuelle Dialog prüft die HTTP-Antwort, verwendet die zurückgemeldete Zahl gestarteter Claims aber nicht als eigene Abschlussbedingung. Prüfe deshalb die erste Ledger-Zeile und ihre terminale Abdeckung, bevor du den Tracker als initialisiert behandelst.

Pause, Fortsetzen und Beenden verändern die Zeitreihe verschieden

Pausieren setzt den Zeitplan auf `paused_user`. Gleichzeitig werden seine laufenden Kindläufe mit einem Abbruchcode als fehlgeschlagen geschlossen und ihre aktiven Reservierungen freigegeben. Fortsetzen aktiviert den Zeitplan, setzt aufeinanderfolgende Fehler zurück und macht ihn sofort fällig. Der stündliche Dispatcher kann ihn anschließend claimen, alternativ startet eine Person ihn manuell. Der abgebrochene Lauf wird weder rekonstruiert noch wird seine Lücke gefüllt.

Beenden archiviert den Zeitplan, setzt seinen Löschzeitpunkt, schließt aktive Kindläufe, gibt Reservierungen frei und entfernt die Zeile aus den normalen aktiven und pausierten Listen. Das ist keine vorübergehende Pause, und die Oberfläche bietet dafür kein Fortsetzen. Historische Lauf- und Abrechnungsevidenz wird durch das Archivieren nicht in Erfolg umgeschrieben. Ein neuer Zeitplan darf die zuvor archivierte Konfiguration später wiederverwenden.

Behandle die angezeigte Zeit als Fälligkeitsgrenze

Der wiederkehrende Dispatcher prüft aktuell stündlich zur Minute 20 UTC eine begrenzte Menge fälliger aktiver Zeitpläne. Eine Zeile kann nach überschrittener Fälligkeit deshalb bald anzeigen und bis zur nächsten Prüfung warten. Nach einem Claim berechnet sich die folgende reguläre Fälligkeit aus der vorigen geplanten Grenze. Provider-Latenz verschiebt die Serie dadurch nicht schrittweise. Ein manueller Lauf oder das Fortsetzen setzt bewusst einen neuen Anker.

Erreicht der Dispatch den Worker nicht, wird der Lauf zu `skipped_dispatch`, seine Reservierung wird freigegeben und der Zeitplan verwendet bei den ersten aktuellen Versuchen einen Retry-Abstand von einer Stunde, bevor er zum normalen Rhythmus zurückkehrt. Die Zeile kennzeichnet diesen Zustand als Retry, statt den Zeitpunkt als gesunden nächsten Lauf darzustellen. Feature-Gate, ungültige aktuelle Mitgliedschaft, Tenancy-Fehler, begrenzter Dispatcher-Rückstau oder Worker-Ausfall können verhindern, dass aus einer fälligen Konfiguration pünktlich Messwerte entstehen.

Lies angefordert, erfasst, ohne Daten, ausstehend und fehlend getrennt

Jeder Kindlauf beginnt als Dispatching und wird mit eintreffendem Fortschritt zu Running. Solange er aktiv ist, gilt die Differenz aus angefordert minus erfasst minus ohne Daten als ausstehend. Erst nach einem terminalen Status wird der Rest fehlend. Die Oberfläche trennt diese Zustände, damit ein frischer Lauf mit null Ergebnissen nicht vor Abschluss wie ein Fehler wirkt.

Succeeded bedeutet, dass der Lauf seinen terminalen Vertrag erfüllt hat. Partial bedeutet, dass Evidenz oder ein ausdrückliches Ohne-Daten-Ergebnis vorliegt, aber kein vollständiger Erfolg. Failed bedeutet keine nutzbare Fertigstellung. Eine Leseprojektion kann eine fehlerhafte Zeile mit positiven Erfasst- oder Ohne-Daten-Zählern zur Anzeige als partiell korrigieren. `skipped_balance` steht für eine Budget- oder Balanceblockade, `skipped_dispatch` für einen angelegten Claim mit fehlgeschlagenem Dispatch. Ohne Daten ist ein ausdrückliches Provider-Ergebnis. Fehlend ist der ungeklärte Rest nach Abschluss.

Nutze das Laufprotokoll als Ausführungs- und Kostenbeleg

Das Protokoll je Zeitplan ist mit den neuesten Zeilen zuerst paginiert und verwendet aktuell standardmäßig eine Richtliniengröße von bis zu 50 Zeilen. Das Health-Diagramm fasst eine begrenzte jüngste Menge zusammen, derzeit 12 Zeilen. Jede Ledger-Zeile enthält Status, Startzeit, angefordert, erfasst, ohne Daten, bei Abschluss fehlend, falls vorhanden einen Supportcode und, sobald verfügbar, die abgerechneten Kosten. Ein Claim für zwei Geräte erzeugt zwei Kindzeilen in einer Gruppe. Fortschrittsband und Zeitplanzusammenfassung können die Gruppe aggregieren.

Der Worker rechnet jede Reservierung gegen die tatsächlich abrechenbare Arbeit ab und gibt den ungenutzten Rest frei. Ein Lauf nur mit Ohne-Daten-Ergebnissen kann null abgerechnete Kosten haben. Dadurch werden weder der Zeitplan noch künftige Erfassungen kostenlos. Auch ein partieller Lauf kann etwas kosten. Für veraltete laufende Zeilen und liegen gebliebene Reservierungen gibt es Abgleichs- und Wiederherstellungspfade. Vor einem Retry bleiben sichtbarer Endstatus, Zähler, Fehlercode, Kosten und Activity-Eintrag die maßgebliche Evidenz.

Nutze Vorgangsstatus und Kostennachweise zur Untersuchung eines Laufs, ohne den geplanten Zeitpunkt als Ausführungsbeleg zu behandeln.

Prüfe den Zeitplan, bevor du seiner Zeitreihe vertraust

Beispiel: Tracking mit kleinem Budget

Häufige Fragen