Dotcom-Monitor Synthetic Monitoring: Browser-Based Uptime Checks

Synthetic monitoring runs scripted checks against your application continuously, simulating what real users do. The word "synthetic" distinguishes it from real user monitoring (RUM), which captures data from actual user sessions. Synthetic monitoring runs whether or not real users are active — it's the active probe, not the passive listener.

Dotcom-Monitor's synthetic monitoring is built around two products: UserView (the monitoring engine) and EveryStep Recorder (the script creation tool). Together they let you monitor multi-step user flows — login, checkout, search, form submission — from multiple geographic locations on a configurable schedule.

UserView vs HTTP Checks: What's the Difference

The distinction matters for how you set up monitoring and what you learn from it.

HTTP checks (ServerView) send a single HTTP request and validate the response. They answer: "Does this URL return a 200 status code with the expected content?" They're fast, lightweight, and run every minute if needed. They don't execute JavaScript, don't load third-party assets, and don't simulate user interactions.

UserView checks launch a real Chrome or Firefox browser, load the full page (including all assets and JavaScript), and then execute a sequence of interactions — click this button, type in this field, wait for this element, assert this text is visible. They answer: "Can a user actually complete this workflow right now?"

The gap between these two is significant. An HTTP check on your login page will pass even if:

• The login form's JavaScript fails to initialize
• The submit button handler throws an uncaught error
• A third-party authentication service is returning errors
• The password field has a broken autocomplete that prevents form submission

UserView catches all of these because it's doing what a user does.

The tradeoff: UserView checks are slower to run (30-120 seconds per check execution vs. under a second for HTTP), more expensive in platform cost, and more sensitive to application changes (script steps break when UI elements change). Use HTTP checks for broad coverage and UserView for critical path coverage.

When to use each:

EveryStep Recorder: How It Works

EveryStep is a Windows desktop application. Download and install it from your Dotcom-Monitor account. On Mac or Linux, run it via a Windows VM — it's a genuine Windows-only tool, not a web app.

Recording a script:

1. Open EveryStep and enter your target URL
2. A browser window opens, controlled by the recorder
3. Interact with the application as a user would — navigate, click, type
4. Each interaction is captured as a script step in the recording panel
5. When done, stop recording and review the captured steps

The recorder captures:

• Navigation events (page loads, redirects)
• Click events (buttons, links, checkboxes)
• Text input (form fields)
• Select events (dropdowns)
• File uploads

Step validation:

Raw recordings just replay actions. A replay that doesn't verify results is insufficient for monitoring. After recording, add assertions to each step:

• Text assertion: Confirm a specific string appears on the page after an action. Example: after clicking the login button, assert "Welcome back" appears.
• Element assertion: Confirm an element exists (or doesn't exist). Example: after adding to cart, assert the cart item count is not zero.
• URL assertion: Confirm the URL contains an expected string after navigation.

Without assertions, a UserView check passes as long as the browser doesn't throw a hard error. A page that loads but shows "Service Unavailable" in the body would pass without assertions. With assertions, it fails — which is what you want.

Editing scripts:

EveryStep generates XML-based scripts that you can edit directly. Common manual edits:

• Replace hardcoded selectors with more robust alternatives (CSS selectors are often more stable than XPath)
• Add explicit waits for dynamic content (wait until an element is visible, not just until the DOM event fires)
• Parameterize credentials (use environment variables rather than embedding passwords in the script)
• Add error handling for optional elements that may or may not appear

Exported scripts are importable into UserView as a new device. After import, validate the script runs successfully at least once in the Dotcom-Monitor dashboard before enabling continuous monitoring.

Monitoring Login Flows

Login is the canonical use case for synthetic monitoring. It's critical, it's fragile, and an HTTP check won't catch most of the ways it can break.

Recording the login script:

1. Start recording on your login page URL
2. Click the username field, type your monitoring account credentials
3. Click the password field, type the password
4. Click the submit button
5. Wait for the redirect to the authenticated state
6. Add a text assertion on a string that only appears when authenticated (user name, dashboard header, account menu)

Monitoring account setup:

Use a dedicated monitoring service account. Don't use a real user account — monitoring runs continuously and generates login events that may interfere with security monitoring or rate limiting. A dedicated account also lets you set specific permissions and rotate credentials independently.

Password rotation is an operational concern: when you rotate the monitoring account password, you need to update the UserView script. Build this into your password rotation runbook.

Two-factor authentication:

2FA on the monitoring account is a problem. Most synthetic monitoring flows can't handle TOTP codes. Options:

• Disable 2FA for the monitoring service account (acceptable risk if the account has limited permissions)
• Use an IP allowlist — add Dotcom-Monitor agent IPs to an allowlist that bypasses 2FA
• Use a direct API token for authentication if your application supports it

Check Dotcom-Monitor's documentation for current agent IP ranges, as these can change when agent infrastructure is updated.

Monitoring Forms and Dynamic Content

Form monitoring beyond login follows the same pattern: record, add assertions, handle dynamic content.

Handling dynamic content:

SPAs and dynamically loaded content require explicit waits. If you click a button that triggers a fetch call and then renders content, your script needs to wait for that content before asserting on it.

In EveryStep, add a Wait step after any action that triggers async content loading:

• Wait for element with ID results-container to be visible
• Wait for URL to contain /dashboard
• Wait up to 10 seconds, then fail the step if the condition isn't met

Avoid fixed time waits (sleep 3 seconds) — these are brittle and slow. Condition-based waits are more reliable and usually faster.

Handling variable content:

Some pages have content that legitimately changes — timestamps, random recommendations, personalized content. Don't assert on specific variable values. Assert on structure:

• "An element with class recommendation-card is present" rather than "The text 'Product XYZ' is visible"
• "The results container contains at least one item" rather than "The results show 42 items"

Form submission with validation:

For form submission scripts, add assertions at each validation step:

1. Submit with valid data → assert success message
2. (Optional) Add a second script for error state testing: submit with invalid data → assert error message appears

Two separate scripts for happy path and error path are easier to maintain than one combined script with branching logic.

Alert Configuration for UserView

UserView alerting follows the same configuration path as other Dotcom-Monitor check types, but the thresholds need calibration.

Alert sensitivity:

UserView checks are more complex than HTTP checks and correspondingly more likely to have transient failures — a slow page load causes a wait timeout, a brief network issue drops a resource. Set your alert to require 2-3 consecutive failures before paging.

Configure your alerts under Scheduler → Alert Contacts → assign to your UserView devices.

Step-level alerting:

When a UserView check fails, the alert includes which step failed. This is the key diagnostic advantage over HTTP checks — you know immediately whether login failed, whether the post-login redirect worked, or whether a specific form action broke.

Capture this in your alert format. The default Dotcom-Monitor email alert includes step failure details. If you're routing to PagerDuty or Slack, configure the webhook payload to include the failed step name and any error message.

Alert escalation:

For critical flows (checkout, signup), configure escalation:

• First failure: Slack notification to #engineering channel
• Second consecutive failure: PagerDuty page to on-call engineer
• Third consecutive failure: SMS to engineering lead

This matches the severity escalation to the confidence level that a real problem exists versus a transient check failure.

Script Maintenance

This is the unglamorous reality of synthetic monitoring: scripts break when applications change. Elements get renamed, pages get redesigned, flows get restructured.

Build maintenance into your process:

• After every deployment that touches UI or flows covered by UserView scripts, check the monitoring dashboard for failures
• Version control your EveryStep scripts alongside your application code
• When scripts break, fix them before the next deployment — don't let broken monitors accumulate

Use resilient selectors:

CSS selectors based on stable attributes (data-testid, id, name) are more resilient than selectors based on text content or visual position. If your development team uses data-testid attributes for test automation, use the same attributes in UserView scripts.

Review quarterly:

Even without deployments, scripts drift from reality. Quarterly reviews of all UserView scripts catch problems before they cause false alerts: verify each script still reflects the actual user flow, update any selectors that have changed, re-record sections that are significantly different.

Synthetic monitoring's value is continuous — it's watching your critical paths around the clock. That value only holds if the scripts accurately represent what users actually experience.