> ## 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

> Optimize your monitor setup for reliability, performance, and efficient delivery.

## Real-Time Frequency

The `frequency_minute` parameter controls how often your monitor scans.

| Setting           | Behavior                                                          | Use Case                                       |
| ----------------- | ----------------------------------------------------------------- | ---------------------------------------------- |
| **`0` (default)** | **Real-time** — signals are detected and delivered as they appear | Most monitors — fastest possible delivery      |
| `1 - 60`          | Fixed interval in minutes                                         | When you want predictable cadence              |
| `60 - 1440`       | Hourly to daily                                                   | Digest-style summaries, lower priority signals |

<Tip>
  With `frequency_minute: 0`, Pubrio detects and delivers signals as they appear — no polling, no delay.
</Tip>

***

## Retry Configuration

When a webhook delivery fails, retries help recover automatically.

| Parameter               | Range | Default | Recommendation                                       |
| ----------------------- | ----- | ------- | ---------------------------------------------------- |
| `max_retry_per_trigger` | 0 - 3 | 1       | Set to 2-3 for critical monitors                     |
| `retry_delay_second`    | 1 - 5 | 1       | Use 3-5 seconds to allow transient issues to resolve |

<Note>
  Retries re-deliver the same payload — they do not re-run the signal detection or incur additional search credits.
</Note>

***

## Process Retry

The [Process Retry](/en/api-reference/endpoint/monitors/process_retry) endpoint lets you re-attempt a specific failed delivery. Key benefits:

* **No charge for failures** — you are not charged credits when a delivery fails. Credits are only consumed on successful delivery.
* **Troubleshooting** — retry a failed log entry to diagnose webhook issues without creating new triggers.
* **Original destination option** — use `is_use_original_destination` to retry with the destination snapshot from the original log, useful when you have updated your webhook URL since the failure.

Find failed deliveries via [Statistic Logs](/en/api-reference/endpoint/monitors/statistics_logs) and retry them individually.

***

## Failure Handling

The `max_failure_trigger` parameter (range: 1-10, default: 5) controls how many consecutive delivery failures are allowed before the monitor automatically pauses.

**Recommended approach:**

1. Set `notification_email` to receive alerts when failures occur
2. Keep `max_failure_trigger` at 3-5 for production monitors
3. Use [Statistic Logs](/en/api-reference/endpoint/monitors/statistics_logs) to diagnose failures — check `error_message` and `response_status_code`
4. After fixing the issue, reactivate via [Update Monitor](/en/api-reference/endpoint/monitors/update)
5. Use [Process Retry](/en/api-reference/endpoint/monitors/process_retry) to re-attempt specific failed deliveries

***

## Polling with Statistics Endpoints

While webhooks handle real-time delivery, the statistics endpoints provide monitoring, debugging, and audit capabilities.

### Overview polling

Use [Monitor Statistics](/en/api-reference/endpoint/monitors/statistics) for a dashboard-level health check:

<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>

Returns aggregate metrics: total monitors, triggers today vs yesterday, success rates, and comparison rates.

### Log-based polling

Use [Statistic Logs](/en/api-reference/endpoint/monitors/statistics_logs) to review trigger history:

<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>

Each log entry includes status, credit usage, signal/company/people counts, processing time, and error details.

<Tip>
  Combine webhook delivery with periodic log polling for maximum reliability: webhooks handle real-time processing, while log polling catches any missed deliveries and provides an audit trail.
</Tip>

***

## Scaling Recommendations

<AccordionGroup>
  <Accordion title="Focused monitors vs. broad filters">
    **Prefer focused monitors over overly broad ones.** A monitor tracking "AI jobs at US enterprise companies" is easier to debug than "all jobs everywhere." Focused monitors also let you route different signal types to different webhook endpoints.
  </Accordion>

  <Accordion title="Webhook endpoint reliability">
    Your webhook endpoint should:

    * Respond within 30 seconds
    * Return `200` immediately and process data asynchronously
    * Handle duplicate payloads gracefully (idempotency)
    * Log all incoming payloads for debugging
  </Accordion>

  <Accordion title="Managing many monitors">
    Use [Get Monitor List](/en/api-reference/endpoint/monitors/monitors) with filtering:

    * Filter by `detection_mode` and `destination_type`
    * Sort by `last_modified` or `last_trigger_at`
    * Search by name with `search_term`

    Use [Monitor Statistics](/en/api-reference/endpoint/monitors/statistics) to spot underperforming monitors quickly.
  </Accordion>
</AccordionGroup>