> ## 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.
**The monitoring API is live, in beta.** The core pipeline (watches →
alerts → webhooks) is production-grade; a few v1.1 features (digest
delivery) are not shipped yet. See
[Known beta limitations](/guides/monitoring/beta-limitations) for the
full list and current latency expectations.
## The three building blocks
| | What it is | When you touch it |
| ----------- | ----------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------- |
| **Watch** | A saved query. Signa runs it on every ingestion sync 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 trademark, the event that produced it, a severity, and where applicable a jurisdiction-aware opposition deadline.
```json theme={null}
{
"id": "alt_01HK7M3QY8VVR0K1GH1A4N2D8B",
"object": "alert",
"watch_id": "wat_01HK7M3QY8VVR0K1GH1A4N2D8C",
"trademark_id": "tm_01HK7N4RY9WWS0L2HJ2A5O3E9C",
"event_type": "trademark.created",
"severity": "critical",
"must_act_by": "2026-05-16T03:59:59.999Z",
"opposition_window_status": "critical",
"created_at": "2026-05-08T14:32:11.428Z"
}
```
For marks in [supported jurisdictions](/guides/monitoring/opposition-windows#coverage), `opposition_window_status` and `must_act_by` are computed for you. Route on `severity` to escalate the matches that need urgent attention.
## 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 up to seven times 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 daily call to [`POST /v1/alerts/lookup`](/api-reference/monitoring/alerts/lookup) to confirm nothing was lost. | Production workflows that can't tolerate a missed alert. |
## 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.