Getting Started with Dotcom-Monitor: First Performance Test

Dotcom-Monitor has a lot of surface area. The platform covers uptime monitoring, full browser checks, transaction monitoring, and load testing — and the UI reflects all of that. If you try to understand everything before running your first check, you'll be reading documentation for an hour before monitoring anything.

This guide skips the theory and gets you to your first working check in under 15 minutes. You'll set up an HTTP check, a full-page browser check, configure alert contacts, and understand what the results are actually telling you.

Account Setup

Sign up at dotcom-monitor.com. Free trial gives you access to all products without a credit card. The trial period is sufficient to evaluate whether the platform fits your needs.

After signing in, you land in the main dashboard. The left navigation breaks down by product:

• ServerView — HTTP/S, ping, port checks
• WebView — full browser page load monitoring
• UserView — transaction/workflow monitoring
• LoadView — load and stress testing
• Scheduler — alert contacts and escalation schedules

Start with ServerView for your first check. It's the simplest and gives you immediate results.

Creating an HTTP Check

In the left navigation, click ServerView → Devices → Add Device.

The "Add Device" dialog is where Dotcom-Monitor's age shows — terminology like "device" for a monitoring check is a legacy of the platform's infrastructure monitoring roots. A device is just a check configuration.

Step 1: Select the device type

Choose HTTP/S. This creates a check that sends an HTTP request to a URL and validates the response.

Step 2: Configure the basic check

• URL: Enter your endpoint. Include the protocol (https://). For your first check, use your homepage or a health check endpoint.
• Name: Something descriptive — Production Homepage - HTTP or API Health Check. You'll have many checks eventually; name them so they're searchable.
• Frequency: Start with 5 minutes. You can lower this to 1 minute for critical endpoints once you've validated the check is working correctly.

Step 3: Configure response validation

This is where most teams underinvest. A check that only validates HTTP 200 status will pass even if your application returns an error page with a 200 status code.

Under Response Parameters:

• Expected Status Code: Set to 200 (or whatever your endpoint actually returns)
• Content Validation: Enter a string that should appear in the response body. For an API, this might be "status":"ok". For a web page, it might be a title or nav element text. The check fails if this string is absent.

Step 4: Set up authentication (if needed)

For authenticated endpoints, the Authentication section supports:

• HTTP Basic Auth (username/password)
• Custom request headers (for Bearer tokens or API keys)
• POST body for form-based login endpoints

For API endpoints that require a token header: expand Request Headers, add your Authorization: Bearer <token> header. The token is stored in the check configuration — use a dedicated monitoring service account with minimal permissions, not your personal credentials.

Step 5: Select monitoring locations

Under Monitoring Locations, select at least 3 agent locations. Spread them geographically — one in North America, one in Europe, one in Asia-Pacific if your users are global.

Multi-location selection matters for false positive reduction: Dotcom-Monitor can be configured to alert only when multiple locations see a failure simultaneously. A single location failure is usually a network blip, not an application outage.

Step 6: Save the device

Click Save. The check starts running immediately on the configured schedule. You'll see results in the dashboard within one check interval.

Setting Up a Full-Page Browser Check

HTTP checks tell you whether your endpoint responds. Full-page browser checks (WebView) tell you whether the page actually loads correctly for users — including CSS, JavaScript, images, and third-party resources.

Navigate to WebView → Devices → Add Device.

Choose browser and device type

WebView supports:

• Chrome (recommended for modern sites)
• Firefox
• Internet Explorer (legacy coverage only)
• Mobile emulation (Chrome mobile, various device profiles)

Select Chrome desktop for your first check. Add a mobile check separately if mobile performance is a concern — mobile and desktop can have dramatically different load profiles.

Configure the URL and check parameters

Same URL as your HTTP check. The key additional settings for WebView:

• Page Load Timeout: Default is 30 seconds. If your page legitimately loads in under 5 seconds, lower this threshold — a false pass from a 28-second load is worse than an alert.
• Block Ads: Optionally block ad network requests during the check. Useful if you want to isolate your application's performance from third-party ad latency.
• DNS Caching: Enable to use cached DNS results during checks. Disable if you're monitoring DNS propagation.

Set performance thresholds

Under Performance Alerts, configure:

• Load Time: Alert if page load exceeds X seconds. Set this to your actual SLA — if your performance budget is 3 seconds, set the threshold at 3 seconds.
• Page Size: Alert if total page weight exceeds a limit. Useful for catching uncompressed asset deployments.

Select monitoring locations

Same approach as HTTP checks: multiple geographic locations, spread based on where your users are.

Save the device. WebView checks take slightly longer to initialize than HTTP checks since they're spinning up real browser instances, but you'll see results within the first check interval.

Configuring Alert Contacts

A check that runs without alerting is useless. Navigate to Scheduler → Alert Contacts → Add Contact.

Email alerts

The most basic setup. Enter the email address for your on-call engineer or team distribution list. Configure:

• Alert on failure: Yes — this is the notification when a check fails
• Alert on recovery: Yes — this closes the loop when an issue resolves
• Postpone alert: How many consecutive failures before alerting. Set to 2-3 to reduce false positives from transient failures.

Slack integration

Under contact type, select Slack. You'll need an incoming webhook URL from your Slack workspace:

1. Go to your Slack workspace → Apps → Incoming Webhooks → Add New Webhook
2. Select the channel where alerts should post
3. Copy the webhook URL into Dotcom-Monitor

Slack alerts are good for team-visible notifications. Keep PagerDuty or SMS alerts for actual on-call paging.

PagerDuty integration

Select PagerDuty as the contact type, enter your PagerDuty integration key. This creates incidents in PagerDuty when checks fail and resolves them automatically on recovery.

Assigning contacts to devices

After creating contacts, go back to each device (check) and assign the appropriate alert contacts. A check with no assigned contacts will run silently.

Navigate to your check → Edit → Alert Contacts tab → select the contacts to notify when this check fails.

Running a Test and Reading Results

After saving your checks, navigate to Reports → Response Time to see initial results.

The response time chart

The main view shows response time over time per monitoring location. What you're looking for:

• Flat baseline: Normal operation — consistent response times from all locations
• Single location spike: Usually a network issue between that agent and your server, not an application problem
• All-location spike: Application or infrastructure issue — this is what you need to act on
• Stepped increase: Gradual degradation, often from a resource leak, database slow query, or traffic growth

The waterfall view (WebView checks)

Click into any individual WebView check result to see the full waterfall. Each row is a resource loaded during the page request:

• Green/blue bars: Normal load times
• Wide bars: Slow resources — investigate these first
• Red bars or missing resources: Failed resource loads — 404s, timeouts, CORS errors
• Long thin bars late in the waterfall: Render-blocking resources that delay page completion

Third-party resources often show up as the slowest items in the waterfall. If Google Tag Manager or a chat widget is adding 2 seconds to your load time, you'll see it here clearly.

Status history

Under Reports → Availability, you get uptime percentage and outage events over any time range. This is the data you report to stakeholders: "99.94% uptime last 30 days, two incidents totaling 32 minutes of downtime."

Alert history

Under Reports → Alerts, you can see every alert that fired, when it resolved, and how long the incident lasted. Use this to track MTTR (mean time to recovery) over time.

What to Do After Your First Check Is Running

Once your first HTTP and WebView checks are running and alerting:

1. Add checks for all critical endpoints — don't just monitor your homepage. Add checks for your login page, API health endpoint, checkout flow (or whatever is business-critical for your application).
2. Lower the check interval on critical paths — 5 minutes is a good starting point, but for production payment processing endpoints, you want 1-minute checks.
3. Set up a maintenance window — before your next deployment, configure a maintenance window in Scheduler so the deployment doesn't trigger a flood of false alerts.
4. Review your alert thresholds after two weeks — once you have baseline data, tune your performance thresholds to match actual performance rather than arbitrary defaults.

The next step from here is UserView transaction monitoring — recording multi-step user flows so you know whether your login, checkout, or signup workflows are working correctly in production, 24/7.