> ## 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.
# Monitoring overview
> Watches detect trademark events you care about. Alerts and webhooks deliver them.
Signa monitoring turns office filings into a feed you can act on. You define what to watch (a specific mark, an owner, a Nice class, a similarity query) and Signa delivers an alert whenever a trademark matches, including the opposition deadline where one applies.
**Alerts typically arrive within a day of office publication.** Signa evaluates every watch against each office's daily data update, so a new filing usually alerts within about a day of the office publishing it, not within minutes of the filing itself. Every delivery is one alert at a time (there is no digest or batched mode yet); if you want your own batching, dedupe by the webhook `webhook-id` header and roll alerts up on your own schedule.
## The three building blocks
| | What it is | When you touch it |
| ----------- | ----------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------- |
| **Watch** | A saved query. Signa evaluates it against every data update and produces alerts for matches. | When you decide what to track. |
| **Alert** | An immutable record of one match. Carries the trademark, the event that triggered it, severity, and a deadline if applicable. | When you process matches in your application. |
| **Webhook** | A signed `POST` to a URL you control, delivered every time an alert fires. | When you want push instead of polling. |
You can use webhooks, polling, or both. Webhooks deliver in seconds; polling gives you a recoverable fallback.
## The five watch types
Pick from five watch types: `mark`, `portfolio`, `owner`, `class`, or `similarity`. See [Watches](/guides/monitoring/watches) for the full query DSL, the required field for each type, and worked examples.
## What an alert looks like
Each alert carries the matched trademark, the event that produced it, a severity, and (where applicable) a jurisdiction-aware opposition deadline. This is the canonical shape returned by [`GET /v1/alerts/{id}`](/api-reference/monitoring/alerts/retrieve) and carried in every webhook delivery:
```json theme={null}
{
"id": "alt_8kLm2nPq",
"object": "alert",
"schema_version": "2026-06-01",
"watch": { "id": "wat_7hRt4xQw", "name": "US class 9, new filings", "type": "class" },
"customer_reference": "matter-2026-0481",
"event": {
"type": "trademark.created",
"summary": "Trademark created",
"diff": []
},
"match": null,
"trademark": {
"id": "tm_9pQs3vNk",
"mark_text": "ACME ROCKETS",
"mark_feature_type": "word",
"office_code": "US",
"status": { "primary": "pending", "stage": "examination" },
"filing_date": "2026-05-01",
"registration_date": null,
"nice_classes": [9],
"owner_name": "Aurora Digital, Inc.",
"as_of": "2026-05-08T14:32:11.428Z",
"links": { "self": "/v1/trademarks/tm_9pQs3vNk" }
},
"deadline": {
"severity": "critical",
"opposition_window_status": "critical",
"must_act_by": "2026-05-16T03:59:59.999Z"
},
"timestamps": {
"occurred_at": "2026-05-08T14:30:00.000Z",
"ingested_at": "2026-05-08T14:31:00.000Z",
"created_at": "2026-05-08T14:32:11.428Z"
},
"links": { "trademark": "/v1/trademarks/tm_9pQs3vNk", "watch": "/v1/watches/wat_7hRt4xQw" }
}
```
For marks in [supported jurisdictions](/guides/monitoring/opposition-windows#coverage), `deadline.opposition_window_status` and `deadline.must_act_by` are computed for you. Route on `deadline.severity` to escalate the matches that need urgent attention. See [Webhooks](/guides/monitoring/webhooks#payload-shape) for the full field reference.
## Choosing how alerts reach you
| Mode | How it works | Best for |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------- |
| **Webhook (push)** | Signa posts each alert to a URL you control. HMAC-signed, retried across up to 7 attempts with exponential backoff. | Production workflows, low latency, on-call paging. |
| **Polling (pull)** | Your code calls `GET /v1/alerts` on a schedule. | Prototypes, internal tools, low volume. |
| **Webhook + reconciliation** | Push for latency, plus a periodic call to [`POST /v1/alerts/lookup`](/api-reference/monitoring/alerts/lookup) to confirm nothing was lost. | Production workflows that cannot tolerate a missed alert. |
See [Handling alerts](/guides/monitoring/alert-handling) for the reconciliation pattern.
## What's next
Pick a watch type, build the query, preview the volume before you go live.
Register an endpoint, verify signatures, handle retries and rotation.
A copy-pasteable Cloudflare Worker or AWS Lambda recipe.
Use the diagnostics endpoint to find out exactly why an alert didn't fire.