Signals
The raw inputs every loop watches — SDK-captured product data, connected integrations, and the sessions 1mn runs itself — and which loop acts on each.
A signal is a piece of real data about your product that a loop reads at its discover stage — a spike in errors, a session where a user got stuck, a revenue dip, a Search Console query you're almost ranking for. Loops don't act on hunches; each one pulls the signal it's responsible for, dedupes against what it's already handled, and decides whether there's work to do. Signals are the "discover" in trigger → discover → decide → act → verify.
They come from three places: most product signal is captured by the 1mn SDK (one install), some comes from integrations you connect, and some 1mn generates itself by driving your app.
Captured by the 1mn SDK
One SDK install — a ~8KB browser snippet — captures five signals with nothing else to wire up:
| Signal | What it is | Where you see it | Acted on by |
|---|---|---|---|
| Pageviews & web analytics | Visitors, paths, referrers | Web analytics tab | The daily brief |
| Errors | Grouped + symbolicated JavaScript exceptions | Watchdog tab | Error triage → a fix PR |
| User feedback | Submissions from the in-app feedback widget | Feedback tab | Filed as draft tickets for you to route |
| Web vitals | LCP · CLS · INP | SEO & GEO tab | The SEO audit (Core Web Vitals) |
| Session replay | Real user sessions, recorded with rrweb | Recordings tab | The Recordings Reviewer |
Errors, feedback, pageviews and web vitals stream from the first deploy. Session replay is off by default — you turn it on from the Recordings tab, and the already-installed snippet lazy-loads the recorder only for sessions that are sampled in (see Session replay).
One install, not one-per-signal
You don't integrate errors, then analytics, then replay separately. The single snippet from the Setup Wizard captures all five, and enabling replay later just writes a flag the snippet already reads — no redeploy. If GitHub is connected, 1mn even opens the install as a pull request for you.
Connected through integrations
Some of the most valuable signal lives in tools you already use. Connect them once in Integrations and the relevant loop starts reading them:
| Signal | Source | Connect it | Acted on by |
|---|---|---|---|
| Organic search | Impressions, clicks, and near-miss queries | Google Search Console | SEO audit, daily brief |
| Revenue | Subscriptions, MRR, and trend | Polar | Daily brief |
| Deployments | Build / deploy status and preview URLs | Cloudflare & Vercel | Coding and error triage target the live deploy |
| Ad performance | Spend, CPA, and delivery for live campaigns | Meta / Google Ads (via the ads loop) | The ads loop audits and scales within your bands |
If an integration isn't connected, the loop that depends on it degrades gracefully — it does what it can from the signal it does have and tells you what's missing, rather than failing.
Generated by 1mn
Two signals don't wait for your users — 1mn produces them by driving your product in a real browser:
- Dogfooding / Cast sessions — AI personas use your app against a staging target, then file what they hit as tickets. See Cast and the Dogfooding routine.
- Watchdog probes — the Watchdog risk-ranks features from recent commits + real-user errors, then probes them in a browser and files a draft ticket for every reproduced failure.
These matter most early, when you have real code but not yet enough real traffic for user signal to be meaningful.
How a signal becomes work
The pattern is the same for every source:
- A loop's trigger fires (a schedule, a webhook, or you).
- It discovers its signal and dedupes against what it already handled — so the same error or the same replay isn't worked twice.
- It decides whether there's anything worth doing right now, and skips if not. A quiet signal means a quiet loop, not a manufactured task.
- If there is work, it acts, verifies, and surfaces the result as a ticket — a fix PR, a draft, a report — gated for your review when the action is irreversible.
Because loops read signal fresh each run, the value compounds: after a fix ships, the loop measures the signal again, and if the pattern persists it reopens the work.
Notes & limits
- Most signal needs the SDK. Without the install, the product-facing loops (error triage, recordings, feedback) have nothing to discover. Connecting your product in the Setup Wizard is what turns them on.
- The dashboard flips to live on the first event. Until your deployed site serves the snippet and sends one event, the SDK-backed tabs show an empty state.
- Signal in, tickets out. You watch signal on its tab, but you act on the Tasks board — that's where every loop surfaces the work a signal produced.
- No signal is acted on blindly. Every loop verifies before it ships and gates irreversible actions for you — see How loops work.