From Selectors to Sentences: Why Nova Act and AgentCore Browser Are My New Go-To for UI Monitoring

I have used CloudWatch Synthetics canaries on real projects, and honestly, they were good enough.

Then AWS published synthetic monitoring with Amazon Nova Act, and it changed how I think about UI monitoring. The way we watch user journeys is shifting from selectors to sentences.

To keep this concrete, I will use my own site, vishnurachapudi.com, as the example. It has real journeys worth watching, like filtering posts and opening an article, and its HTML changes whenever I redesign it.

This is an architectural take, not a hands-on one. The hands-on comparison comes in part two.

How a canary would monitor my site

A CloudWatch Synthetics canary is a script running in a managed Lambda function on a schedule, written with Puppeteer, Playwright or Selenium. Each step finds an element by a CSS selector, then clicks, types and checks. Every run stores screenshots, a HAR file and logs in S3, and publishes success and duration metrics to CloudWatch.

For my "open a blog post" journey, the canary clicks a[href="#blog"], then the "Agentic AI" filter button, then the link to the post, and checks the heading.

A canary is cheap per run. The real cost sits elsewhere:

• Maintenance. The next time I rename a class or move the filter tabs, the canary goes red even though the site works. Someone has to fix the script.
• Artifacts on every run. Lambda time, a headless browser, and screenshots written to S3 every few minutes for every journey, most of which nobody opens.

So canaries are cheap to run and expensive to own.

The shift: from monitoring scripts to intent

With Amazon Nova Act, each step is an instruction in plain English. Nova Act looks at a screenshot of the page, decides where to click, and repeats until the instruction is done. It does not care whether the filter is a <button> or a <div>, only whether "Agentic AI" is visible on screen, the way a real visitor would.

The same four steps become a monitor anyone can read and review. You stop maintaining selector scripts and start describing what a visitor is trying to do.

I explored Nova Act on its own earlier this year (here is what broke and what it can do). What makes it production-ready is running it on AgentCore.

The building blocks

• EventBridge Scheduler triggers the journey every 15 minutes. The same agent can also run from a CI/CD pipeline after each deploy, which turns a monitor into a release gate.
• AgentCore Runtime hosts the agent with its own IAM role. This is where it becomes agentic: the agent has tools beyond the browser. It can publish metrics, send alerts, call an API, or check that a form submission actually arrived.
• Amazon Nova Act turns each English instruction into browser actions.
• AgentCore Browser runs every session in its own isolated environment, so every check runs in a private browser rather than on a shared machine. Session recordings go to an S3 bucket, so when a journey fails at 3 AM, I replay what the agent saw instead of guessing from a stack trace.
• CloudWatch and SNS close the loop with a SuccessPercent metric, alarms, and an email or Slack alert.

One design note: in the AWS reference design, a failed journey arrives only as an SNS email. Have the agent publish its own SuccessPercent and Duration every run, plus a heartbeat alarm for runs that never report.

Beyond "is the page up?"

An uptime check tells you the server answers. UI monitoring tells you a visitor can actually do what they came for. With Nova Act on AgentCore, the same journeys give you three kinds of monitoring:

1. Journey monitoring: run the key journeys against production on a schedule.
2. Post-deploy checks: run them right after every deploy, before visitors notice a break.
3. Agentic checks: with runtime tools, the monitor can verify more than the screen, such as "the résumé button leads to a PDF that actually downloads".

The catch: your prompts are the new monitors

Natural language does not mean no engineering. Your prompts are now your monitors, and vague ones cause problems. An instruction like "find something interesting about AWS" gives the agent too much freedom. It can wander between sections, retry, or get stuck in a loop, and every extra step costs time and inference. AWS's own post notes adaptation succeeds around 90% of the time, so single-attempt checks can raise the occasional false alert.

What I would enforce from day one:

• One intent per act() call. "Filter the posts by Agentic AI" beats "find the agentic posts and open the Nova one".
• Explicit assertions. Use act_get() with a schema, such as a boolean, rather than trusting the agent "probably finished".
• Bound the steps. Cap steps per instruction so a confused agent fails fast.
• Keep secrets out of prompts. Type passwords through the browser page, not inside the instruction.
• Choose how strict each prompt is. If a redesign hides the Writing link inside a menu, a canary goes red, while an agent may find it and pass, even though visitors now struggle. Decide which behaviour you want for each journey.

Trade-offs at a glance

My take

Canaries are not going away. For one-minute heartbeat checks, API monitoring and latency SLOs, they are still the right tool.

But for UI monitoring, especially journeys that change often or cross third-party pages like SSO or payment, Nova Act on AgentCore Browser is where I would start today. You get natural-language journeys instead of selector scripts, monitors that survive a redesign, a private browser with recordings in S3, and a runtime with tools that makes monitoring truly agentic.

The engineering work does not disappear. It moves from maintaining selectors to writing clear, bounded, well-asserted instructions, and to publishing the metrics you need.

References: Implementing synthetic monitoring using Amazon Nova Act · aws-samples/sample-nova-act-synthetic-monitoring