Know the moment a page changes.
Point a Monitor at a selector, a visual zone, or a screenshot region. Writ checks as fast as every 10 seconds and turns the change into a trigger.
The change becomes a trigger - fan it out or run a workflow.
The change you notice late is the one you missed.
The pages you depend on change without telling you - a status flips, a policy updates, a listing appears. Most have no feed for the part you care about, and a text-only check misses layout and image changes entirely.
- Most pages have no feed for the part you care about.
- Text-only checks miss layout and image changes.
- A change you notice late is a change you missed.
Baseline anything, detect everything.
As fast as every 10 seconds - honestly priced.
Faster detection costs more cloud run-time, and a full browser render costs more than an HTTP check. Writ makes both explicit so you can tune cadence against cost, with nothing hidden in the fine print. A lightweight HTTP check fetches the page and diffs a selector; a JS render drives a real browser so dynamic, script-built content is captured. Pick HTTP for high-frequency selector watches; reach for a render only when the page truly needs one.
Honest monitor floors, by plan
| Plan | Static (HTTP) | Dynamic (JS render) |
|---|---|---|
| Free | 5 min | 15 min |
| Starter | 60s | 10 min |
| Pro | 60s | 10 min |
| Growth | 30s | 5 min |
| Scale | 10s | 2 min |
| Enterprise | 10s | By arrangement |
These are floors, not guarantees - you can always check less often. Higher-frequency checks consume more of your plan's included cloud run-time.
...or run it on a schedule.
When you don't need sub-minute detection, set the Monitor on a slower recurring interval instead - every few minutes, hourly, or once a day. Recurring runs are interval-based, from minutes to daily, so a once-a-day check can post a digest of what changed overnight without watching the page in real time. A schedule is its own Automation trigger - wire the cadence in Automations.
...or run it on a schedule.
When you don't need sub-minute detection, set the Monitor on a slower recurring interval instead - every few minutes, hourly, or once a day. Recurring runs are interval-based, from minutes to daily, so a once-a-day check can post a digest of what came back in stock overnight without watching the page in real time.
A schedule is its own Automation trigger - wire the cadence in Automations.
From detection to action.
When a Monitor detects a change, that event becomes an Automation trigger that fires a workflow or a notification - automatically, faster than a person can react.
Watch a status and notify on change.
# Monitor: page, every 10s, selector ".status"
# On change → Automation trigger → notify + record
GET https://api.usewrit.app/v1/change-watch/latest
Authorization: Bearer wt_…
→ { "url": "…", "before": "In review", "after": "Approved", "changed_at": "…" } Call the latest change as an API, or let it fire a workflow automatically.
Change monitoring questions.
Text, visual, or both?
Both - selector and text baselines catch content changes; visual-zone and screenshot-region baselines catch layout and image changes.
How fast can it check?
As fast as every 10 seconds on Scale and Enterprise. Free checks every 5 minutes; each plan sets its own floor.
What's the difference between HTTP and JS checks?
An HTTP check fetches the page and diffs a selector - cheap, so it can run at high frequency. A JS render drives a real browser to capture dynamic, script-built content, which costs more per check. Use HTTP where you can and a render only where the page needs it.
Is this allowed?
Writ runs on your own accounts, with your own credentials and data, on sites you are authorized to use. You watch pages you are authorized to access; respect each site's terms and rate limits.
Catch every change that matters.
Point a Monitor at any page and turn a change into an instant action.