Testing the Journey, Not the Page
You test pages and you ship journeys. Every page in a checkout can render correctly in isolation while the checkout itself is broken, because what breaks is rarely a page — it is the state carried between them, the redirect after login, the form that validates and never submits, the step that works until the one before it sets a cookie it did not expect. No amount of loading individual URLs finds that. Synthetic monitoring runs the whole sequence, in a real browser, on a schedule.
The thing manual testing cannot be
You did test the flow. You tested it on the day you built it, on your machine, with your session, against whatever data you had. That is one sample from one configuration at one moment, and the value of it decays immediately — the next deploy, the next dependency update, the next change to a third-party script can all break it, and none of them will prompt anyone to go and click through the checkout again.
Automation is not a more thorough version of what you did manually. It is a different thing: the same journey, repeated indefinitely, against production, without anyone remembering. That repetition is the entire product, and it is the part a person cannot supply.
Production is where the interesting failures are
Staging does not reproduce the conditions that break flows. It has different data, often a different third-party configuration, frequently a different certificate and definitely a different traffic profile. Flows break in production because of things production has: a real payment provider that started rejecting a card type, a session store under load, a consent banner that now covers the submit button on one viewport.
This is also why the flows most worth automating are not always the obvious ones. Login and checkout get attention because they are visible. The ones that surprise people are password reset, email verification, and anything used rarely enough that it breaks in March and is discovered in September by the one person who needed it.
Where it will annoy you
A synthetic check is written against a user interface, and you change user interfaces for a living. Redesign the login form and the flow fails while the site is perfectly healthy — a false alarm caused by your own work. Enough of those and the team learns to ignore the alert, which is a worse state than not having the check.
Two things keep it manageable. Write steps against the most stable selectors available, which usually means something semantic rather than a generated class name that changes when the bundler does. And treat the flow as something that gets updated in the same pull request as the interface it exercises, not as configuration somebody set up once and left.
What makes a failed run useful
Pass or fail on its own is nearly worthless for a front-end failure, because it starts the investigation at reproduction — which is the slow part, and often impossible for something that happened at 4am and resolved itself. What you want back is the step that failed, a screenshot of the browser at that instant, and the requests the page made along the way. With those three, most failures are diagnosed without reproducing anything.