Signals & monitoring
How problems get found before you report them
A signal is an observation from a connected system that may justify work: an error, an increasing support backlog, stale data, or a website performance regression. The platform model connects observations to tasks; each application supplies its own data sources and checks.
The point of monitoring is to surface signals and open tasks from them, so a problem becomes work without a human noticing it first.
What works today
The current website-diagnosis workflow is a Storefront use case of that model. Diagnosis starts from a URL and gets sharper as you connect data — your site's repository, GA4, Search Console, your commerce platform. You can connect these yourself; see Connections.
It already opens tasks on its own from what it finds. Those cards are system-owned: the sync controls their title, description, and priority, so editing them by hand won't stick.
What's changing
Three things are honestly not there yet:
- It runs on demand, not continuously. The direction is always-on monitors — a site performance monitor, an AI usage monitor — rather than a report you ask for. That's the consolidation this page's status refers to.
- Report quality needs work. Findings are uneven.
- The hand-off into tasks loses context. Not every actionable becomes a task, and the tasks that do land carry too little of why — you often can't see which check failed or what it measured.
Because of that last point, a task opened from a signal is worth re-reading before an agent starts on it. Adding the missing context in a comment is the difference between a useful run and a wasted one — see Writing a task.
Connecting the loop
A signal is only fully useful when it can be measured against something. That's what Objectives are for, and why they're the next thing after monitoring: without them you can say a task shipped, but not whether it moved the number it was meant to move.