> ## Documentation Index > Fetch the complete documentation index at: https://docs.signa.so/llms.txt > Use this file to discover all available pages before exploring further. # Known beta limitations > What the monitoring beta does today, what's coming in v1.1, and the latency expectations to design against The monitoring API (watches, alerts, webhooks) is **live, in beta**. The core pipeline — ingestion sync → evaluation → alert → signed webhook delivery — runs in production and is what beta customers should build against. This page is the honest list of what is *not* there yet and the operational characteristics to design around. ## Delivery modes: only `always_per_alert` `delivery_mode` accepts only `always_per_alert` today — one delivery per alert. The digest modes (`digest_above_threshold`, `digest_only`) are planned but not yet available; sending them to create or update returns `400`, and digest batching/suppression is not live for any watch. If you need batching today, do it on your side: dedupe by `webhook-id` and roll alerts up on your own schedule. ## Alert latency: bounded by office sync cadence An alert fires after **the office publishes data → Signa ingests it → the evaluator matches it**. Webhook delivery itself takes seconds after detection; the dominant term is the office's publication-to-ingest gap. Concretely for the USPTO: Signa's daily ingest runs at **01:01 UTC**, with retry rails at **05:01 and 13:01 UTC** that catch late upstream publication. A new US filing therefore typically alerts **within \~24 hours of USPTO's daily file publication** — not within minutes of the filing itself. Other offices follow their own sync cadences (see [Data freshness](/guides/data-freshness)). Intra-day USPTO ingestion is on the roadmap but not committed. ## Preview latency and the time budget [`POST /v1/watches/preview`](/api-reference/monitoring/watches/preview) runs synchronously under a \~20-second server-side budget, with each database read capped at 10 seconds: * `mark` and `owner` previews and narrow `class` previews complete in a few seconds. A broad watch without a text query (for example one class in `US` over 30 days) can hit the 10-second read cap and return a `preview_timeout` `504` after about 10 seconds. * `similarity` previews over broad scopes and long trial windows are the heaviest and may approach the budget. * Counts can come back labeled `estimate_basis: "candidacy_upper_bound"` (upper-bound estimate), the budget can end a heavy preview with a `preview_timeout` `504` (`retryable: false` — narrow the query), and concurrent previews `429` with a `Retry-After`. Full semantics on the [Preview Watch](/api-reference/monitoring/watches/preview) page. ## Diagnostics: bounded data windows [`GET /v1/watches/{id}/diagnostics`](/api-reference/monitoring/watches/diagnostics) reconstructs the evaluation trace from retained provenance, and those retention windows are finite — change records 90 days, delivery audit records 30 days, indexing status 14 days, outbox 7 days. Past a horizon the response says so explicitly (`evaluated: false` with a `reason`, and the `data_window` object lists every horizon) rather than guessing. Diagnose recent misses promptly. ## Logs page: origin-side only The dashboard's request Logs page records requests that reached the API origin. The rare error served directly from the CDN/WAF edge (an edge `5xx` during a deploy or an edge block) **does not appear there** — and edge-served `502` bodies carry a fixed sentinel `request_id` (`req_edge_static_502`) rather than a real origin request id, because the request never produced one. For those, capture the `x-amz-cf-id` **response header** plus the timestamp, URL, and method, and email [support@signa.so](mailto:support@signa.so) — that is enough for us to trace the edge hit. (WAF-generated `403`/`413` blocks and the edge rate-limit `429` carry the `req_unknown` sentinel, which is not traceable on its own — include the `x-amz-cf-id` header and timestamp for those too. An oversized URI returns `414`, and oversized or malformed request headers return `400` from the load balancer or `494` when they exceed the CDN's larger header cap, all with an HTML body and no sentinel at all; quote `x-amz-cf-id` for those as well.) The `request_id` in an error body is the thing to quote for JSON errors that came from the API origin itself. ## No public status page yet Signa does not currently publish a status page. Use the [health endpoints](/api-reference/health) for machine-readable liveness and readiness from your side (see [Uptime monitoring](/guides/monitoring/uptime-monitoring)), and [support@signa.so](mailto:support@signa.so) for incident questions. ## Webhook trademark identity The `alert.created` payload carries the matched trademark at `data.alert.trademark.id`, matching the rich nested alert resource. The former root-level `trademark_id` and `trademark_record_id` fields are not present. ## Events feed (beta) The per-org event feed ([`GET /v1/events`](/api-reference/monitoring/events/list), [`GET /v1/events/{id}`](/api-reference/monitoring/events/retrieve)) is documented and callable. It is **beta**: the ledger, the `evt_*` ids and the `sort=id&after=` replay rail are stable enough to build on, but the per-event `data` payloads are versioned by `payload_version` and their shape is not yet promised. Pin `payload_version` in your consumer. Retention is 30 days; a checkpoint older than that returns `410 replay_window_expired` and you resume from the oldest page instead. `alert.created` projection is unconditional, while `trademark.*` events are projected when the event projector is enabled and the mark belongs to one of the organization's portfolios. `?portfolio_id=` filters every family, `alert.created` included, against the portfolio membership recorded at event time — an alert on a mark outside the portfolio is not in that portfolio's feed. `occurred_at` is when Signa produced the event, never the office's own date: ingestion time for `trademark.*` and `office_action.*`, alert-creation time for `alert.created`. Those two direct families also carry `source_date`, the office-reported date at day precision (null when the feed reports none), and `portfolios` — the membership snapshot with your `external_ref`, frozen at record time. Webhook consumers should route alert-derived trademark changes on `payload.data.alert.event.type`; the old flat `payload.data.event_type` path is not part of the current envelope. ## Telling us about it Beta means your feedback steers what ships next. Rate limits too tight, latency that breaks a workflow, a missing recipe — email [support@signa.so](mailto:support@signa.so).