> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pubrio.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Best Practices & Polling

> Optimieren Sie Ihre Monitor-Einrichtung für Zuverlässigkeit, Performance und effiziente Zustellung.

## Echtzeit-Frequenz

Der Parameter `frequency_minute` steuert, wie oft Ihr Monitor scannt.

| Einstellung        | Verhalten                                                                  | Anwendungsfall                                                     |
| ------------------ | -------------------------------------------------------------------------- | ------------------------------------------------------------------ |
| **`0` (Standard)** | **Echtzeit** — Signale werden erkannt und zugestellt, sobald sie auftreten | Die meisten Monitore — schnellstmögliche Zustellung                |
| `1 - 60`           | Festes Intervall in Minuten                                                | Wenn Sie einen vorhersehbaren Rhythmus wünschen                    |
| `60 - 1440`        | Stündlich bis täglich                                                      | Digest-artige Zusammenfassungen, Signale mit niedrigerer Priorität |

<Tip>
  Mit `frequency_minute: 0` erkennt und liefert Pubrio Signale, sobald sie auftreten — kein Polling, keine Verzögerung.
</Tip>

***

## Retry-Konfiguration

Wenn eine Webhook-Zustellung fehlschlägt, helfen Wiederholungsversuche bei der automatischen Wiederherstellung.

| Parameter               | Bereich | Standard | Empfehlung                                                              |
| ----------------------- | ------- | -------- | ----------------------------------------------------------------------- |
| `max_retry_per_trigger` | 0 - 3   | 1        | Für kritische Monitore auf 2–3 setzen                                   |
| `retry_delay_second`    | 1 - 5   | 1        | 3–5 Sekunden verwenden, damit vorübergehende Probleme sich lösen können |

<Note>
  Wiederholungsversuche liefern denselben Payload erneut aus — sie führen die Signalerkennung nicht erneut aus und verursachen keine zusätzlichen Suchkredite.
</Note>

***

## Process Retry

Mit dem Endpunkt [Process Retry](/de/api-reference/endpoint/monitors/process_retry) können Sie eine bestimmte fehlgeschlagene Zustellung erneut versuchen. Wesentliche Vorteile:

* **Keine Kosten bei Fehlern** — Ihnen werden bei einer fehlgeschlagenen Zustellung keine Credits berechnet. Credits werden nur bei erfolgreicher Zustellung verbraucht.
* **Fehlerbehebung** — Wiederholen Sie einen fehlgeschlagenen Log-Eintrag, um Webhook-Probleme zu diagnostizieren, ohne neue Trigger zu erzeugen.
* **Option für ursprüngliches Ziel** — Verwenden Sie `is_use_original_destination`, um mit dem Ziel-Snapshot aus dem ursprünglichen Log erneut zu versuchen — nützlich, wenn Sie Ihre Webhook-URL seit dem Fehler aktualisiert haben.

Fehlgeschlagene Zustellungen finden Sie über [Statistic Logs](/de/api-reference/endpoint/monitors/statistics_logs) und können sie einzeln wiederholen.

***

## Fehlerbehandlung

Der Parameter `max_failure_trigger` (Bereich: 1–10, Standard: 5) steuert, wie viele aufeinanderfolgende Zustellungsfehler zulässig sind, bevor der Monitor automatisch pausiert wird.

**Empfohlenes Vorgehen:**

1. Setzen Sie `notification_email`, um bei Fehlern benachrichtigt zu werden
2. Halten Sie `max_failure_trigger` für Produktionsmonitore bei 3–5
3. Verwenden Sie [Statistic Logs](/de/api-reference/endpoint/monitors/statistics_logs), um Fehler zu diagnostizieren — prüfen Sie `error_message` und `response_status_code`
4. Reaktivieren Sie den Monitor nach der Fehlerbehebung über [Update Monitor](/de/api-reference/endpoint/monitors/update)
5. Verwenden Sie [Process Retry](/de/api-reference/endpoint/monitors/process_retry), um bestimmte fehlgeschlagene Zustellungen erneut zu versuchen

***

## Polling mit Statistik-Endpunkten

Während Webhooks die Echtzeitzustellung übernehmen, bieten die Statistik-Endpunkte Monitoring-, Debugging- und Audit-Funktionen.

### Überblicks-Polling

Verwenden Sie [Monitor Statistics](/de/api-reference/endpoint/monitors/statistics) für eine Dashboard-Statusprüfung:

<CodeGroup>
  ```bash cURL theme={null}
  curl -X POST https://api.pubrio.com/monitors/statistics \
    -H "Content-Type: application/json" \
    -H "pubrio-api-key: YOUR_API_KEY" \
    -d '{ "profile_id": 1 }'
  ```
</CodeGroup>

Liefert aggregierte Kennzahlen: Gesamtzahl der Monitore, Trigger heute vs. gestern, Erfolgsraten und Vergleichsraten.

### Log-basiertes Polling

Verwenden Sie [Statistic Logs](/de/api-reference/endpoint/monitors/statistics_logs), um den Trigger-Verlauf zu überprüfen:

<CodeGroup>
  ```bash cURL theme={null}
  curl -X POST https://api.pubrio.com/monitors/statistics/logs \
    -H "Content-Type: application/json" \
    -H "pubrio-api-key: YOUR_API_KEY" \
    -d '{
      "profile_id": 1,
      "monitor_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
      "page": 1,
      "per_page": 10
    }'
  ```
</CodeGroup>

Jeder Log-Eintrag enthält Status, Credit-Verbrauch, Anzahl der Signale/Unternehmen/Personen, Verarbeitungszeit und Fehlerdetails.

<Tip>
  Kombinieren Sie die Webhook-Zustellung mit periodischem Log-Polling für maximale Zuverlässigkeit: Webhooks übernehmen die Echtzeitverarbeitung, während Log-Polling verpasste Zustellungen erfasst und einen Audit-Trail liefert.
</Tip>

***

## Empfehlungen zur Skalierung

<AccordionGroup>
  <Accordion title="Fokussierte Monitore vs. breite Filter">
    **Bevorzugen Sie fokussierte Monitore gegenüber übermäßig breiten.** Ein Monitor, der „KI-Jobs bei US-Enterprise-Unternehmen" verfolgt, lässt sich leichter debuggen als „alle Jobs überall". Fokussierte Monitore erlauben es Ihnen außerdem, unterschiedliche Signaltypen an unterschiedliche Webhook-Endpunkte zu routen.
  </Accordion>

  <Accordion title="Zuverlässigkeit des Webhook-Endpunkts">
    Ihr Webhook-Endpunkt sollte:

    * Innerhalb von 30 Sekunden antworten
    * Sofort `200` zurückgeben und Daten asynchron verarbeiten
    * Doppelte Payloads sauber handhaben (Idempotenz)
    * Alle eingehenden Payloads zu Debugging-Zwecken protokollieren
  </Accordion>

  <Accordion title="Verwaltung vieler Monitore">
    Verwenden Sie [Get Monitor List](/de/api-reference/endpoint/monitors/monitors) mit Filterung:

    * Filtern nach `detection_mode` und `destination_type`
    * Sortieren nach `last_modified` oder `last_trigger_at`
    * Suchen nach Namen mit `search_term`

    Verwenden Sie [Monitor Statistics](/de/api-reference/endpoint/monitors/statistics), um schnell unterdurchschnittlich performende Monitore zu erkennen.
  </Accordion>
</AccordionGroup>