Browser Monitoring

Run a real browser through a real user journey — log in, click through, check out — on a schedule, with a screenshot of every step and a video of every failure.

STATUS: INCOMPLETE — 6 open clarifications (see Open questions at the end of this draft; resolve before publishing).

What is a browser monitor?

A browser monitor drives an actual browser — Chromium, Firefox or WebKit — through a list of steps you define, on a schedule. It navigates, clicks, types, waits, and asserts that the things a user needs to see are actually on the page. Your JavaScript runs. Your CSS applies. Your login form submits for real.

The whole script is one check. If every step passes, the monitor is Up. If any step fails, the monitor is Down, and the run tells you which step broke, what the error was, what the page looked like at that moment, and — from the recorded video — how it got there.

Example: "Open the site, click Sign in, type my test account's email and password, submit, and require the text 'Dashboard' to be visible. If a user can't log in, page me."

This is the check for the things a request cannot see. A plain HTTP check on your login page gets a 200 back from a page whose submit button is broken by a bad deploy. It reports Up. Every customer of yours is locked out. Only a browser can tell you the difference.

When to use one

• Login flows. The single highest-value browser check. Authentication breaks in ways that return perfectly healthy HTTP responses — an expired third-party script, a CSP change, a bad redirect, a form field renamed.
• Checkout and payment journeys. Add to cart → enter details → reach the confirmation page. Revenue paths deserve a check that proves the whole path, not that four URLs return 200.
• Signup and onboarding. The flow your growth depends on, and the one nobody manually tests after a deploy.
• Single-page apps. If your page is an empty
  until JavaScript fills it, an HTTP check is reading the empty div. A browser check reads what the user reads.
• Search, filters, dashboards — anything where the answer arrives after a fetch, not in the first response.
• Third-party breakage you inherit. A payment widget, a chat bubble, a consent banner that starts covering your primary button. Console errors and the screenshot make these obvious.

When to use something else

A browser monitor is the most expensive check Enori runs, in money and in time. The pattern that works: a Website monitor on every public URL, and a small number of browser monitors on the journeys that actually make you money.

What it costs

Browser monitors are the one monitor type with their own price. Everything else is included in your plan; a browser monitor is billed per monitor, per month, on top of it.

Your first browser monitor is free, at a 30-minute interval. Every account gets it — Base, Pro and Business alike, and during the 14-day trial.

After that, the price depends only on how often it runs:

Those four are the only intervals a browser monitor can run at. There is no 1-minute browser check.

The prices above are the monthly rate, and they are what the wizard shows you. On a yearly plan the add-on is billed yearly too — a subscription can't mix monthly and yearly items. See Billing & Subscription, and Open questions for the yearly figure.

Things worth knowing before you create one:

• You are charged when you click Create. There is no separate "buy an add-on first" step — creating the monitor is the purchase. The final wizard button says exactly what you are agreeing to: "Create and start monitoring — €9.99/mo".
• The charge is prorated. You pay for the remainder of the current billing period, and the amount lands on your next invoice rather than being taken immediately.
• It still uses a monitor slot. A browser monitor counts toward your plan's monitor limit like any other monitor (10 on Base, 50 on Pro, 200 on Business). The add-on price is on top of your plan — it does not buy you an extra slot.
• Pausing a paid browser monitor does not stop the charge. Pausing is temporary and deliberately keeps the subscription item alive so that resuming doesn't bill you a second time. If you want the charge to stop, delete the monitor — that cancels the line item and puts a prorated credit on your next invoice.
• You need an active plan or trial to create any browser monitor, free one included. Without a live subscription the wizard stops at the interval step and offers you the plans page instead.

See Billing & Subscription for invoices, VAT and proration in general.

How it works

On every check, Enori runs your steps in order, top to bottom:

1. A fresh, isolated browser is started — no cookies, no local storage, no session from the previous run.
2. Your encrypted variables are decrypted into the run, and any {{token}} in a step's value or selector is filled in.
3. Each step executes in turn. Screenshots are taken as it goes; a video records the whole run.
4. If a step fails, the run stops there. Remaining steps are recorded as Skipped.

What counts as Up: every step completed and every assertion passed.

What counts as Down: any step failed — an element never appeared, an assertion was false, a navigation errored, or the whole script ran past its timeout.

What doesn't count either way: if Enori's own infrastructure fails to run your check, the result is recorded as an infrastructure error and is excluded from your uptime percentage. Our bad day doesn't become your bad number.

Every run starts logged out, from scratch. A browser monitor cannot "stay signed in" between checks — it signs in every single time, which is the entire point of pointing one at a login flow.

Response time for a browser monitor is the wall-clock duration of the whole journey, so it sits much higher than a single-request monitor's. On the detail page this figure is labelled Page Load.

Where checks run from. Browser checks run from Enori's dedicated browser infrastructure in Europe, from one location. Unlike Website, Ping, Port and DNS monitors, they are not re-verified from a second region — a failure is recorded on the first observation. If you allowlist by IP, the addresses are listed in Monitoring IP addresses.

Setting one up

Go to Monitors, click Add Monitor, and choose Browser Monitor ("Real Chromium browser — user flows, clicks, forms, screenshots"). That opens a dedicated five-step wizard — Steps → Secrets → Alerts → Interval → Confirm — separate from the wizard the other monitor types use.

Screenshot: the Browser Monitor card on the monitor-type picker.

Step 1 — Steps

The fastest correct start is the AI Step Generator. Type what you want tested in plain English and click Generate steps:

"Log in with test@example.com, navigate to settings, verify the profile page loads"

Enori opens the page, looks at the real DOM, and writes a step list against the elements that are actually there. The description can be up to 500 characters. Generating replaces whatever is currently in the step list, so generate first and hand-edit after — not the other way around.

Generated steps are a starting point, not gospel. Read them, fix the selectors that guessed wrong, delete the ones you don't need.

Screenshot: the AI Step Generator panel with a description typed in and a generated step list below it.

Editing steps by hand. Click the pencil on any step to expand it. Drag the handle to reorder (or focus it and use ↑/↓). Each step has an Action, an optional Selector, an optional Value, and a Description that becomes the step's label in results.

Give every step a description. It is the difference between an alert that says "step 4 failed" and one that says "Submit login form failed".

Step 2 — Secrets

Any {{token}} you used in a step shows up here, waiting for a value. See Credentials and encrypted variables below — read that section before typing a real password.

If your steps reference no tokens, this step says "No secrets needed" and you move on.

Step 3 — Alerts

One alert fires per failed check, not per step. If five steps fail in one run you get one alert, and it names the failing step.

Sensitivity works differently here than on HTTP monitors on purpose: each browser check is a full user journey that takes 10–60 seconds, so a single failure usually means real users are affected. Start at alert immediately and only loosen it if you have a genuinely flaky step you can't fix.

Full detail on channels, escalation and on-call rotas lives in Alerts.

Step 4 — Interval

Pick one of 5, 10, 15 or 30 minutes, each showing its monthly price. If this is your first browser monitor, only 30 minutes is selectable and it's marked Free.

This step also carries two settings that change what the check sees:

Device / viewport. Choose the device the check emulates:

There's also an optional Custom User-Agent (up to 512 characters) that overrides the device's default.

Browser engine. Chromium, Firefox or WebKit:

Screenshot: the interval picker with the four priced tiers, plus the device and engine selectors below it.

Step 5 — Confirm

A summary of everything, the price you're about to commit to, and — before you commit — a dry run.

Use the dry run. It executes your step list against the live site right now and shows you per-step pass/fail plus screenshots. It saves nothing: no check result, no uptime impact, no alert, and no charge. It is the difference between finding a bad selector in ten seconds and finding it in your first alert.

The same dry-run panel is in the Edit dialog, so you can re-test after changing a step without waiting for the next scheduled check. Two limits: dry runs and AI step generation share a budget of 10 requests per minute, and a run_subtest step can't be dry-run ("save the monitor first to test subtests").

When it passes, click Create and start monitoring.

Screenshot: the confirm step showing the summary card, the dry-run panel with green step results, and the priced CTA.

Step types

Nineteen actions are available. Selector and Value columns show which fields each one uses.

Navigation and interaction

Waiting

Assertions

Assertions are what turn a click-through into a check. A script with no assertions only proves nothing threw an error.

Subtests

Every login flow you write is the same six steps. Run subtest lets you write them once. Build a "Log in" browser monitor, then start your checkout monitor with a single Run subtest → Log in step.

Currently API-only. The step editor lets you choose the Run subtest action but has no field for picking which monitor to run, so a subtest step can only be configured through the REST API or the MCP server today. A run_subtest step saved from the UI without a target is rejected with "run_subtest step is missing SubtestMonitorId". See Open questions.

The rules:

• The referenced monitor must be your own and must be a browser monitor.
• One level only. A subtest cannot itself contain a subtest.
• The subtest's steps are inlined into the parent run and shown grouped under Subtest: <name> in the results. They don't count against the parent's 25-step limit — that limit applies to the steps you author, and each run_subtest counts as one.
• The subtest's own encrypted variables come with it. You can override any of them on the calling step — with a literal value, or with {{token}} to pass one of the parent's variables through.
• Pausing the referenced monitor does not stop it running as a subtest. Pausing stops its own schedule only; its steps still execute inside every parent that calls it.
• If the referenced monitor is deleted, the step fails with "Referenced subtest monitor no longer exists" — so the parent goes Down and tells you exactly why.

Credentials and encrypted variables

You will need to put a real password into a browser monitor. Here is exactly what happens to it.

How to use one. Write {{variable_name}} anywhere in a step's Value or Selector, then supply the value on the Secrets step:

Up to 20 variables per monitor.

Names are case-sensitive. {{Password}} and {{password}} are different variables. The wizard blocks you from continuing if a step references a token nothing defines — it will not let you save a monitor that would fail every check.

Two-factor authentication

Set a variable's type to TOTP and paste the Base32 secret from your authenticator app — the same string behind the QR code, e.g. JBSWY3DPEHPK3PXP. Enori generates a fresh 6-digit code on every check, so a monitor can walk through a 2FA-protected login. Enori validates that the secret is real Base32 when you save it.

Reference it like any other variable — {{totp_code}} in the Type step for the code field.

What Enori promises about your secrets

• Encrypted at rest with AES-256-GCM, an authenticated cipher, before the value ever reaches the database.
• Never returned by the API. Listing a monitor's variables returns names and types only. There is no endpoint, anywhere, that gives a value back — not to you, not to anyone.
• Never shown in the UI after you save. You can replace a value; you cannot read it back.
• Decrypted only in memory on the machine running your check, for the duration of that check.
• Deleted with the monitor.

What you should still do

• Use a dedicated test account, not a real customer's and not an admin's. Give it the least privilege that still exercises the journey.
• Don't put secrets anywhere but a variable. A password typed directly into a step's Value is stored as ordinary configuration, and it will appear in screenshots of that step.
• Screenshots capture what's on screen. A password field renders as dots, so a typed password isn't visible — but if your app ever displays a token, an API key or personal data on screen, that pixel data is stored with the check. Know which pages your script visits.
• Rotate the test account's password on your normal schedule. Deleting a variable is blocked while a step still references it, so update the value instead.

Reading the results

Open the monitor to get a single scrolling page of everything the last check saw.

The stat row — five cards across the top:

Step Results is the card you'll actually live in. Every step, in order, with its duration, a status dot, and a thumbnail screenshot you can click to enlarge. The collapsed summary reads like "3/7 — step 4 failed" or "7/7 passed". A failed step is highlighted in red with the error message inline, and steps after it are marked Skipped.

When a step fails and there's a comparable screenshot from the last successful run, Enori shows them side by side — "Last success" vs "Current (failed)". This is usually the fastest way to see what changed.

AI Failure Analysis turns the raw error into two to four sentences of plain English, with a Suggested fix where there is one — typically a better selector.

Video Recording — a video is recorded on every check but kept only when the check fails, because storing successful runs would be a lot of storage for something nobody watches. On a passing check the card reads "No video — videos are only recorded on failed checks". When a video exists you can play it inline or Download video.

Console Errors lists JavaScript errors from the page, up to 100 per check. The card is hidden entirely when there are none. This catches a whole class of problems where the page technically loads but is broken underneath.

Network stats — four figures for the last check: Requests, Transferred, DOM loaded, Page load.

Performance charts Core Web Vitals over 24 hours, 7 days or 30 days — LCP, CLS and INP over time, with a Duration Trend tab that marks failed checks.

Check History lists recent runs so you can open any past check and see its steps and screenshots.

Screenshot: the Step Results card with one failed step expanded, showing the inline error and the side-by-side screenshot comparison.

How long artifacts are kept

Data retention is 30 days on Base, 60 on Pro, 90 on Business. Failure evidence is deliberately kept for the full window while successful screenshots are pruned to the last five — the failures are what you go back and look at. If you need a failure kept longer than your plan's window, download the video and screenshot while they're there.

Deleting a monitor deletes its screenshots and videos immediately.

Self-healing

Selectors break because front-ends change. A class gets renamed, a button gets restructured, and a check that was testing your login starts testing your CSS.

When a step's selector no longer matches, Enori tries to find the same element another way. If it succeeds, the check continues and passes instead of paging you — and the working selector is saved to your monitor so the next check doesn't have to rediscover it.

Enori first tries alternative locators it recorded for that element on previous successful runs, and falls back to working out the right element from the page structure. Either way the replacement is verified against the live page before it's used — a heal that doesn't actually work isn't applied, and the check fails normally.

You are told, not asked. You get a notification — "{monitor} auto-healed a step" — the monitor shows a Healed badge in the monitor list, and the step carries an L2 or L3 chip in Step Results whose tooltip reads Healed: old → new. A Self-Healing panel on the detail page shows the before/after selector with two buttons:

• Accept — keep the new selector. Nothing further changes; it's already live.
• Revert — put the original selector back. Use this when the healing latched onto the wrong element — a different button that happens to look similar.

Assertions and waits are never healed. Assert element, Assert text and Wait for element are excluded on purpose: those steps exist to fail when the thing isn't there, and healing them would defeat the check.

Self-healing is always on and there is currently no setting to disable it. If you don't want a selector silently replaced, use Revert — and consider a data-testid on the element, which is the selector least likely to need healing in the first place.

Review healed steps rather than ignoring them. A heal is a signal that your UI changed; sometimes the honest answer is that the check should now be failing.

Screenshot: a step row with the Healed badge, and the Accept / Revert controls.

When a monitor keeps failing

A browser monitor that fails repeatedly is usually a broken script, not a five-alarm outage — and re-running a broken script every five minutes helps nobody.

So after 5 consecutive failed checks, Enori automatically slows the monitor down to one check per hour. You get a notification when this happens (it appears in your bell as a distinct amber event, not a red alert). The monitor is not paused and it keeps alerting normally — it just runs less often.

It restores itself. On the very next successful check, your original interval comes straight back and you get a second notification. You don't have to do anything — though once you've fixed the cause you can click Check Now rather than waiting up to an hour for the next scheduled run.

Your billing does not change while a monitor is throttled. You keep the interval you're paying for; it's the failing period that runs slower.

If this isn't what you want, open the monitor, click Edit, and go to the Settings tab → Auto-throttle on repeated failures. You can:

• Suppress it entirely for this monitor — it will run at your chosen interval forever, even while failing.
• Change how many consecutive failures trigger it (1–100).
• Change which interval it slows down to.

Leave any field empty to inherit the default of 5 failures → 1 hour.

Re-enabling a monitor after a lapsed subscription

This is a different situation from throttling — nothing is wrong with your script, the billing stopped. What happens depends on how it stopped:

• A payment failed and you then fixed it. Everything resumes automatically, paid browser monitors included, on the same subscription. There is no second charge and nothing for you to do.
• You cancelled and later subscribed again. Your free browser monitor resumes automatically. Paid browser monitors stay paused — their billing was cancelled with the subscription, so switching one back on starts a new, prorated charge and is therefore a deliberate choice rather than something we do for you.

A paused paid browser monitor shows a Re-enable button on its detail page. See Open questions — this button currently fails, and the working path is the REST API or MCP.

Changing a monitor later

Open the monitor and click Edit for a three-tab editor:

• Steps — the same editor as the wizard. If the last run failed, the failing step is flagged in place with its error, so you can fix it where you can see it.
• Variables — add, replace or remove secrets. You can change a value; you can never read one back. Removing a variable a step still uses is refused.
• Settings — name, tags, timeout, device, engine, subtest-target toggle, and the auto-throttle overrides.

Changing the interval is separate, because it changes what you pay. On the monitor's detail page, the Check interval card has a Change interval button. Pick a new tier and Enori shows you the exact proration before you commit — "You'll be billed €3.50 (prorated) on your next invoice", or a credit if you're moving down to a cheaper tier. It is a real figure from your billing account, not an estimate. Nothing changes until you click Confirm change.

Upgrading the free monitor off 30 minutes turns it into a paid monitor — see Open questions below for the current path.

Alerts

Browser monitors use the same alerting as every other monitor type: channels (email, Slack, Discord, Teams, webhook, PagerDuty, SMS), escalation policies, on-call schedules, and repeat reminders. Set them up once in Alerts and point any monitor at them.

What's specific to browser monitors:

• Down fires when a check fails, subject to your sensitivity setting, and names the failing step. It covers both kinds of failure — the site being unreachable, and your script's assertion being false — because from a user's point of view they're the same event.
• Recovered fires when it passes again — but only if you were told it was down. If the failure was deferred by Alert after N minutes down and the check passed again before that delay elapsed, you get neither message. See Alerts for why.
• Enori's own infrastructure failing is never alerted and never counted against your uptime. You'd be paged for our problem, which isn't a thing we do.

Three browser events land in your notification bell (and as a push, if you use the mobile app) rather than going to your alert channels — they're informational, not incidents:

See Notifications for the bell in general.

During a maintenance window, browser checks keep running — you still get screenshots and performance data through your deploy — but the results are marked as maintenance, alerts are suppressed, and the window is excluded from your uptime figures.

Browser monitors also feed SLOs, uptime reports and status pages like any other monitor.

FAQ

Is my first browser monitor really free?

Yes — one per account, fixed at a 30-minute interval, on any plan including the trial. It's a real monitor with all the same features, not a trial mode.

Why can't I run a browser check every minute?

A browser check starts a real browser and drives a real journey — it takes 10–60 seconds and costs roughly a thousand times what an HTTP request costs. Five minutes is the floor, and for most journeys 10 or 15 minutes catches everything a 5-minute check would.

Does a browser monitor use one of my plan's monitor slots?

Yes. The monthly add-on price is on top of your plan; it doesn't buy an extra slot. If you're at your plan's limit you'll need to free a slot or add capacity before creating another monitor of any type.

If I pause a paid browser monitor, do I stop paying?

No. Pausing keeps the subscription item alive so that resuming doesn't charge you again. Delete the monitor to stop the charge — that cancels the line item and puts a prorated credit on your next invoice.

Can I monitor something on my internal network?

No. Browser monitors only reach public http:// and https:// URLs. Private, loopback and link-local addresses are blocked at navigation time, and this is a hard security boundary, not a setting. Point the check at a publicly reachable staging or production URL.

Can someone read the password I stored?

No. Values are encrypted with AES-256-GCM before storage and there is no API or UI path that returns one — you can replace a value, never read it. See Credentials and encrypted variables.

Do failed checks count against my uptime?

Yes — a failed check is downtime. But checks that fail because of Enori's own infrastructure are excluded from your uptime percentage, and checks during a maintenance window are excluded too.

My check passed but the page looked wrong. Why?

Almost always: no assertion covering the thing that broke. A script that clicks through without asserting only proves nothing errored. Add an Assert text or Assert element for the thing a user must actually see.

Why is my browser monitor's response time so much higher than my website monitor's?

Because it measures a different thing: the whole journey — every navigation, every wait, every click — not one request. A five-step journey taking 8 seconds is normal.

Can one browser monitor call another?

Yes, with a Run subtest step, one level deep — currently configurable through the API or MCP rather than the step editor. See Subtests.

Can I turn self-healing off?

Not today. If a heal picked the wrong element, use Revert on the step. Assertions and waits are never healed, so a check can still fail the way you intended it to.

Can I manage browser monitors through the API?

Yes — create, update steps, manage variables, run a dry run, change intervals and read results are all available in the REST API and through the MCP server.

Troubleshooting

"Element not found" on a step that works when I click through manually

The element wasn't there yet. A manual click-through is slower than a script, so you never notice the gap.

Add a Wait for element step before the failing step, targeting the element you're about to interact with. Prefer that to a fixed Wait — it's faster when the page is fast and more patient when it's slow.

The check times out

Your script needs more than its budget. Look at the per-step durations in Step Results to find where the time actually goes — it's usually one step, not general slowness.

Then either raise Timeout (30–120s, up to 300s on Business), remove fixed Wait steps in favour of Wait for element, or shorten the journey. If a single step is taking 45 seconds, the answer is on your side, not in the timeout field.

Every check fails with a variable-looking value typed into the field

The step typed the literal text {{password}} instead of the secret. That means no variable with that exact name exists — variable names are case-sensitive, so {{Password}} will not match a variable called password.

Open Edit → Variables, check the exact spelling, and fix the token in the step.

The login step fails but the credentials are correct

Common causes, in the order worth checking:

1. Two-factor is on the account. Add a TOTP variable with the account's Base32 seed and a step that types {{totp_code}}.
2. A bot-protection or CAPTCHA challenge. Allowlist Enori's monitoring IPs, or exempt your test account.
3. A consent or cookie banner is covering the form. Add a step that dismisses it first.
4. Rate limiting on repeated logins from one address. Exempt the test account.

Run a dry run after each change — it's free and immediate.

A step started failing right after a deploy

Look at the side-by-side screenshot comparison on the failed check. If the element moved or was renamed, either accept the healed selector Enori proposes or update the selector yourself.

The monitor is only checking once an hour and I didn't change anything

It failed 5 checks in a row and was automatically slowed down. Fix the underlying failure — the original interval returns by itself on the next successful check. See When a monitor keeps failing.

I get no screenshots for a step

Screenshots are captured for steps that do something visible. Pure wait and assertion steps don't get their own screenshot by design — the step before them shows the same screen.

Open questions

This section is for the Enori team and must be removed before this guide is published.

1. The "Step Timing" tab on the Performance card is a "coming soon" placeholder. A customer who clicks it gets an empty state reading "Step timing breakdown — coming soon … This tab will light up once there's demand." Should the guide document the tab as unavailable, or is the tab being hidden before launch? (Per-step durations are available today, in the Step Results card.) Looked at: upnest-frontend/components/monitors/detail/BrowserPerformanceChart.tsx:137-138, 387-395.

1. There is no in-product control to upgrade the free browser monitor's interval. The wizard promises "You can upgrade the interval after creation", but on the free monitor's detail page the interval card renders static text "Upgrade to change interval" with no button — the Change interval button is rendered only for already-paid monitors. The backend supports the free→paid upgrade, and the monitors-list bulk Interval… action appears to reach it. What is the intended customer path, so the guide can document it exactly? Looked at: upnest-frontend/components/monitors/detail/BrowserIntervalSettings.tsx:41-51, upnest-frontend/components/monitors/create/BrowserWizardStepInterval.tsx:59-63, upnest-frontend/components/monitors/BulkEditMenu.tsx:35-48.

1. run_subtest is offered in the step editor but has no target field, so a customer cannot build a subtest in the UI at all — the step saves only if subtestMonitorId is supplied, which only the REST API and MCP do. Should the guide document subtests as API-only (as currently drafted), or is the picker landing before launch? The ApiFlow editor has the equivalent input. Looked at: upnest-frontend/components/monitors/create/BrowserWizardStepBuilder.tsx:88-96, 222-296 (no subtestMonitorId input; run_subtest in neither NEEDS_SELECTOR nor NEEDS_VALUE), vs upnest-frontend/components/monitors/apiflow/ApiFlowStepCard.tsx:248-262.

1. The "Re-enable" button on a paused paid browser monitor cannot succeed. ApiClient.reenableBrowserMonitor POSTs with no body, but POST /api/monitors/{id}/browser/reenable takes [FromBody] ReenableBrowserRequest with a [Required] int IntervalSeconds on an [ApiController] — so the request is auto-rejected with 400 and the customer sees "Failed to re-enable browser monitor". The MCP tool, which sends a body, works. The guide currently points at the API instead; should it, or is the fix landing first? Looked at: upnest-frontend/lib/api.ts:3212-3217, src/UpNest.Api/DTOs/MonitorDto.cs:1783-1788, src/UpNest.Api/Controllers/MonitorsController.cs:10433-10435.

1. What does a yearly-plan subscriber actually pay for a browser add-on? The four prices (€2.99 / €4.99 / €5.99 / €9.99) are hard-coded monthly figures in BrowserIntervalHelper.GetPrice, and that is what the wizard, the confirm CTA and the interval card display — but a yearly subscriber is charged against the addon_browser_*_yearly Stripe price, whose amount lives in Stripe and is not in the repo. The guide needs the real yearly figures (and, separately: the UI showing "€2.99/mo" to a yearly subscriber may itself be wrong). Looked at: src/UpNest.Core/Helpers/BrowserIntervalHelper.cs:40-47, src/UpNest.Core/Helpers/AddonLookupKeys.cs:30-47, upnest-frontend/lib/browser-utils.ts:1-6.

1. The "Allow as subtest target" toggle is not enforced for browser monitors. The Settings tab presents it as a permission gate ("Other browser monitors can reference this one via run_subtest steps") and warns when you disable it with dependents — but neither the save-time validator nor the runtime checks the flag, so turning it off does not stop other monitors running it as a subtest. The ApiFlow equivalent is enforced (SUBTEST_NOT_TARGET). Should the guide mention the toggle at all? It is currently omitted. Looked at: src/Enori.BrowserExecutors/Services/SubtestExpander.cs:84-178 (no check), src/UpNest.Api/Controllers/MonitorsController.cs:12216-12248 (no check), vs src/UpNest.Infrastructure/Services/ApiFlow/ApiFlowSubtestExpander.cs:254 (enforced).