SmartFlow RouteWatch is reliability monitoring for x402 routes. I take a baseline of every route you list, re-check it on an hourly cadence, and when the contract a buyer-agent reads changes or breaks, you get an alert with the evidence attached: what was observed, what it was before, and how to reproduce it. Read-only. No access to your keys, your wallet, or your infrastructure.
The monitoring runs on the same measurement stack the observatory publishes from.
An x402 route rarely dies loudly. It keeps returning a response, your dashboard stays green, your uptime monitor is satisfied, and the machine buyer on the other side quietly stops being able to pay you. These are the defect classes I actually catch, because I have caught each of them on live routes.
A route that was listed, discovered and payable drifts out of that state. It disappears from the catalogue, or it stays listed while the thing behind it no longer answers the way the listing promises. Nothing in your own stack reports this, because from your side the process is still running.
The 402 challenge is still served, but a buyer-agent can no longer complete against it: the
payment block is malformed, the advertised metadata fails validation against the schema shipped
beside it, the declared amount and the atomic value disagree, or the route answers with
something other than a payment challenge. The rejection happens on the buyer side and is never
reported back to you. Your endpoint looks healthy and simply stops earning.
The recipient address, the asset, the network, the price or the challenge headers change between one check and the next. Sometimes that is a planned rotation. Sometimes it is a middleware upgrade that rewrote a field nobody was watching. Either way, the terms a buyer agreed to yesterday are not the terms on offer today, and the buyer finds out before you do.
This is not hypothetical. An audit of a single route has surfaced a metadata block that failed validation against its own schema, which is exactly the condition a cataloguing facilitator rejects without telling the operator. The endpoint kept serving its challenge normally the whole time. The only symptom was an absence: it never appeared where buyers look. RouteWatch exists because that class of defect is invisible to the operator by construction, and because it can appear on a route that was fine last week.
Fixed scope, fixed price, monthly billing, cancel any time. Invoice (card or transfer) or USDC.
Incident Response replaces the previous endpoint audit tiers. One price, everywhere.
Severity is assigned by the check that fired, not by how the finding feels. Every alert carries exactly one.
A CRITICAL that turns out to be noise is a defect in my system, not a judgement call about yours. Every one that fires gets reviewed against that standard.
Nothing in that loop needs your cooperation to work, which is the point. If a route can only be checked with your help, it is not being checked the way a stranger checks it.
No demo, no discovery session, no onboarding sequence. You fill in one form and the baseline starts.
I need public URLs. That is the whole list.
Read-only throughout. No API keys, no wallet access, no private keys, no seed phrases, no credentials, no repository access, no infrastructure access, no dashboard logins. I never send a payment, so nothing can be spent. If your route is behind auth or an allowlist and a stranger cannot reach it, I cannot monitor what a stranger sees, and I will say so instead of taking your money.
The probe volume is small and spread out. It is less than one buyer-agent evaluating you.
RouteWatch is run by the operator of SmartFlow Observatory: one person, pseudonymous, full time on x402 measurement. You will not find a team page or a headshot here. What you will find is a body of public work you can open and judge before you send a single URL.
x402 weekly intelligence, published every Sunday on Substack. Measurements first, methodology attached, and when a number was wrong, the correction ran in the same channel that ran the number.
The x402 response validator, the AIR receipt format and the methodology repository live on GitHub: pinned releases, test vectors, schema files generated from the live databases this monitoring runs on.
Defect reports and proposals argued in the open in the x402 protocol repository, including a conformance corpus now being built jointly with another maintainer. The arguments and the mistakes are all on the record.
The observatory keeps a public corrections section. The house rule is printed on every report: check the numbers, especially mine. A monitoring service is only worth paying for if its operator treats his own claims that way.
Pseudonymous by choice, accountable by artifact. Every claim on this page routes to something you can open.
Your monitor asks whether the process is alive. It gets a response and reports green. RouteWatch asks whether a machine buyer can still pay you, which is a different question with a different answer. A route can return a perfectly healthy response while the payment challenge behind it is malformed, the recipient address has changed, or the resource has dropped out of the catalogue buyers discover you through. Those are the states that cost money, and they all look like uptime.
No. Nothing goes into your repository, your runtime, your CI or your infrastructure. Monitoring runs entirely from the outside against your public URLs, which is the same vantage point a buyer-agent has. If you want checks inside your own pipeline as well, the validator is public and free and you can wire it in yourself. That is independent of this subscription.
One finding per defect, in a fixed shape: severity, what was observed, what the baseline held, when it changed, the raw response the verdict came from, the command that reproduces it, the fix, and how you prove the fix landed. It is written so an engineer can act on it without a meeting, and so you can disagree with it by checking the evidence rather than by arguing with me. Recovery gets its own note in the same format. Read a full example.
You email and say stop. Billing is monthly and ends with the period you have already paid for. There is no contract term, no notice window, no exit call, and no attempt to talk you out of it. If you cancel, the baselines and the incident history I hold for you are yours to take with you on request.
Bank invoice (payable by card or transfer) or USDC on Base, whichever suits your accounting. Subscriptions bill monthly on the date you start. Incident Response is paid up front and its invoice states the 50% credit against a first month of monitoring, so you can expense the whole thing cleanly if you subscribe afterwards. Ask for whatever the invoice needs to say for your side and it will say it.
Send the list of routes. I take the baseline, the checks start on their hourly cadence, and the first thing you get back is the record of what your routes look like when they work.
Questions, portfolios that do not fit a plan, procurement paperwork, NDAs:
info@smartflowproai.com
Text only, async, worldwide.