See what changed on a public page.
Longwatch records normalized lines added and removed between successful checks.
Pricing pagesDocumentationStatus pages
Monitoring for agents that are not always running
Your agent can leave.The watch stays.
Longwatch polls a small set of public sources, stores change events, and lets a later agent run retrieve only what it has not seen through a saved cursor.
No accountNo API keyREST + MCPUSDC on Base
Example alert streamwatch_7f2a
- Pricing page changed+ “Annual plan now available”09:41
- New Form 4 filingNVDA · open-market purchase · $1.2M10:03
- New feed itemRelease notes · version 2.410:18
- Price threshold crossedbitcoin above $150,00010:22
poll since #17cursor #21
Current capabilities
A small set of persistent watches.
Longwatch is a working public experiment. It turns changes from supported public sources into the same cursor-based alert format. It does not browse authenticated sites, make decisions, or execute downstream actions.
Receive only unseen feed items.
Each alert contains the item title, link, and publication date when available.
News feedsRelease notesBlogs
Record a configured threshold crossing.
Reports when a supported asset crosses a USD threshold or exceeds a configured 24-hour move.
AboveBelow24h move
Longwatch reports the event. It does not trade.Track new filings by ticker and form.
Alerts include decoded 8-K items and parsed Form 4 transactions when those fields are available.
8-KForm 410b5-1 flags
How it works
Create a watch. Poll it later.
Longwatch runs the poller and stores alert history. The caller stores a watch ID, secret key, and cursor.
Define the watch
Send a supported public URL, ticker, coin, or feed through REST or MCP. Longwatch captures the baseline.
Let the agent exit
The managed poller keeps working after the process, container, chat, or scheduled task is gone.
Return with a cursor
Poll later with since. Receive only unseen alerts and save the new cursor for next time.
Try before you fund
A real result. Zero setup.
Run the same SEC parsers used by standing watches. No account, API key, request body, or wallet required.
$ curl https://longwatch.dev/demo # response { "result": { "filings": [{ "form": "4", "summary": "Open-market purchase …", "insider": { "value": 1240000 } }] }, "watch": { "create": "POST /watches" } }
Pricing
Usage-based pricing.
Longwatch uses x402 for payment. There is no signup, subscription, minimum purchase, or API key.
$0.005 USDC
Create a durable watch and poll it as often as your workflow needs for 7 included days.
- First baseline included
- Unlimited polling inside the window
- Renew only when the next poll is due
- Idempotent paid creation
| One-shot check | $0.001 |
| Poll included window | free |
| Renew another 7 days | $0.005 |
| Free trial watch | 24h |
| MCP connect & list | free |
Use your interface
A normal API. A native MCP server.
Both surfaces call the same handlers and return the same structured results. Choose the interface your agent already understands.
MCP
Connect over Streamable HTTP. Listing tools is always free; paid tools state their price before execution.
View MCP server card →{
"mcpServers": {
"longwatch": {
"url": "https://longwatch.dev/mcp"
}
}
}REST
Use ordinary JSON and HTTP. OpenAPI 3.1 describes every route, input, output, price, and free alternative.
Open the API specification →$ curl -X POST https://longwatch.dev/watches \
-H 'content-type: application/json' \
-H 'idempotency-key: unique-id' \
-d '{"type":"edgar","ticker":"NVDA"}'Questions
The details that matter.
How is this different from a cron job or Visualping?
It is not a fundamentally new monitoring primitive. Longwatch packages scheduling, source state, retries, diffs, and cursor-based alert history behind one API. Technical users can build the same system; Longwatch is for callers that prefer not to operate it.
Why polling instead of only webhooks?
An intermittent agent may have no public address or process waiting for a webhook. Cursor polling lets it pull on its own schedule without losing events. Paid watches can also deliver webhooks when the caller has somewhere to receive them.
What happens when a source fails?
Transient errors are retried. Repeated failures produce a watch_error alert; recovery produces watch_recovered, so silence never masquerades as “nothing changed.”
How long does a watch live?
A watch expires after 7 days without a poll; polling revives it. Alert history keeps the most recent 500 events per watch.
What does an agent need to persist?
Save the returned watch_id, secret key, and latest cursor. The next poll passes the cursor as since and receives only newer events.