Introducing TinyFish Monitor: Subscribe to the web

We didn't set out to build a monitoring product. We noticed people building one on top of us.

Over the last few months, the same usecase kept showing up in Search and Fetch traffic: one URL fetched on a fixed cadence, or one query rerun every morning with a 24-hour recency window. A cron job on one side, a diff script on the other, and an agent in the middle reading the whole result every time to decide if anything moved.

Pricing pages. Job boards. Regulator sites. Product listings. Different targets, identical plumbing.

That plumbing is the least interesting code anyone writes and the most expensive to run. Every check re-reads a full page. The comparison happens in the agent's context, which is the priciest place to do it. And almost every check ends the same way: nothing happened. Then it runs again in an hour.

Monitor is that loop, as a primitive. Set one up from the dashboard with no code, or from the API with one call. Today it's available to every TinyFish account.

What it does

Monitor checks a webpage or a search topic on a schedule and tells you when something you care about changes.

It's like subscribing to a page. You point it at a target, you write what matters in plain English, and it does the checking, the comparing, and the judging. You hear back when the thing you named actually happens. The rest of the time it stays quiet.

Two kinds of target:

Page. You know the URL. Monitor fetches it fresh on every check (no cache, ever), keeps a snapshot, and diffs it against the last one. Pricing pages, changelogs, status pages, docs, a single listing.

Topic. You don't know the URL yet. Monitor reruns a search with a recency window and flags results that weren't there last time. Funding news bounded to the sites you trust, job posts across a set of career pages, new guidance from a handful of agencies.

Both take the same goal, the same schedule, and deliver the same way: email, webhook, or the dashboard.

The part that isn't a diff

Anything can tell you a page changed. That was never the hard part. The hard part is that a page changes constantly and almost none of it is your change. A footer year rolls over. A feature gets reworded. A "last updated" timestamp ticks. A raw diff shows you all of it and leaves you to figure out which line matters.

So Monitor takes a goal. Something like:

• "The Pro plan price drops below $500"
• "A new research role opens at Anthropic. Ignore every other company."
• "A state publishes new guidance on prior authorization"

When a check finds a change, Monitor hands the change (not the page) to a small, fast model along with your goal and asks one question: does this meet your goal? The answer is stored with the check as meaningful or not meaningful, with a one-line summary of what moved and why it passed. Meaningful changes are what get delivered. Everything else stays in the history, with the full diff, if you ever want to look.

Who pays for the judgment

This is where the cost of monitoring actually lives.

If you build this yourself, every check that finds a change produces a diff. On a long page that diff runs to thousands of tokens, and it goes into your model's context so the model can answer "does this matter?" You pay for that question, and all the context and reasoning that goes into answering it, on every check, forever. And on a page that changes cosmetically all day, most checks are just noise. Every copy edit costs real dollars.

Monitor does that step for you, on our side, as part of the check. The change goes to our judge with your goal, the verdict comes back, and you or your agent only ever sees the result. You don't run a model. You don't send the diff anywhere. You don't get a second bill for the analysis. The cost of deciding what matters is ours, not yours.

A few other things we decided on purpose:

• The judge only runs when something changed. Unchanged checks never touch a model.
• A failed judgment never fails the check. You still get the raw diff.
• Failures are never silent. A page that stops responding or a schedule that fails to fire shows up as its own outcome, so a broken monitor can't look like a quiet one.

How to use it

From the dashboard: go to Monitor, pick Page or Topic, add the target, set a schedule, write your goal, choose email or webhook. Monitor runs once immediately to capture a baseline, then follows the schedule.

From the API, it's one call:

curl -X POST "https://agent.tinyfish.ai/v1/monitors" \
  -H "X-API-Key: $TINYFISH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "fetch",
    "name": "Competitor pricing",
    "config": { "url": "https://example.com/pricing", "format": "markdown" },
    "schedule_cron": "0 9 * * *",
    "purpose": "A plan price changes",
    "webhook_url": "https://example.com/webhooks/monitor"
  }'

Swap type to search and give it a query and recency window for a Topic monitor. Pause, resume, edit, run now, and delete are all there too. The full reference is at docs.tinyfish.ai/monitor.

Five things to set up today

Same recipe every time: pick the type, give it the target, set a schedule, write the goal, choose where it lands. Here's what that looks like for the five we see most.

1. A competitor's pricing page
Page monitor on the URL, markdown format, once a day at 9 AM. Goal: "A plan price or plan name changes. Ignore copy edits and feature descriptions." Deliver to a webhook your agent listens on, or to email if a person owns the response. What arrives: which plan moved, old price, new price. A reworded feature bullet doesn't arrive at all.

2. A product listing
Page monitor on the listing URL, every hour. Listings churn constantly (badges, review counts, "also bought" rows), so the goal does the work: "The price drops below $40 or the item comes back in stock. Nothing else." Deliver to webhook. What arrives: the price or the stock state, once, the check it happened on.

3. A company's leadership page
Page monitor, weekly is plenty. Goal: "A person is added to or removed from the leadership team. Ignore title wording changes." Email is fine here since the reader is usually a human doing research. What arrives: the name and whether they joined or left. Run this across the companies you track and you've replaced a quarterly manual sweep.

4. A regulator
Topic monitor, because you don't know the URL of guidance that hasn't been published yet. Query something like "prior authorization guidance" with a 24-hour recency window, bounded to the two or three agency domains you care about, checked daily. Goal: "New official guidance or a rule change on prior authorization. Ignore news coverage, commentary, and meeting notices." What arrives: the new document's URL and a one-line summary of what it says.

5. Job posts
Topic monitor, query the role ("AI research scientist"), recency 24 hours, bounded to career pages, daily. Goal: "A new research role opens at Anthropic or DeepMind. Ignore every other company and ignore reposts." What arrives: the role and the link, the morning it goes up. Same setup works for competitor hiring if you flip the goal to "any engineering role at these three companies."

The pattern in all five: the target and schedule are easy, and the goal is where you tell Monitor what to shut up about. Write the exclusion, not just the inclusion.

Pricing

For the first 72 hours, every check is free.

Run up to 50 active monitors at a time, each checking as often as every 30 minutes, and pay nothing for any of it until September 25.

After the free window, Monitor is billed per check from the same wallet, with the judgment included in the price and failed checks free.

Built for agents

Monitor's end user is the same as every other TinyFish primitive: an agent.

The webhook carries what changed, whether it met the goal, and a short summary, so an agent reads one line about what moved instead of re-reading the page it already read yesterday. Monitor also runs on the same wallet and the same API key as Search, Fetch, Browser, and Agent. Nothing new to provision.

What's next

This is a first release and we know where the edges are. One URL per monitor for now, so watching a fleet of pages means a fleet of monitors. Field-level scoping (watch the price, ignore the description) is coming, and so is Slack delivery. Longer term, Monitor becomes the scheduling and judgment layer for every TinyFish primitive, not just Search and Fetch.

Go set one up at agent.tinyfish.ai/monitor.

Then tag @Tiny_Fish with the goal you wrote.

We read everything.