Last updated: 2026-04-14
Website Monitoring Types Explained
Different services fail in different ways, so the right monitor type depends on what you want to verify.
This guide explains the monitoring types currently available in the dashboard, what each one checks, and when to choose Site, API, or DNS monitoring.
For the broader strategy behind monitor design, uptime vs availability, SSL coverage, and false-positive reduction, see the University uptime monitoring hub.
In the current Add/Edit Monitor dashboard flow, these are the three monitor types you can actively configure end to end. After you choose a type, the same form lets you set the target, validation, check interval, and any plan-dependent monitoring locations.

Site Monitors
Site monitors are the default choice for checking whether a page or endpoint is reachable and behaving the way you expect.
If you mainly care that a page loads, returns the right status, and optionally contains specific content, Site monitoring is the best place to start.
How it works:
- Sends an HTTP or HTTPS request to your URL
- Checks whether the response matches your validation rules
- Measures how long the response took
Best for:
- Websites and web applications
- Landing pages
- Login pages, careers pages, and public dashboards
- Basic uptime checks where availability comes first
Helps you catch:
- Full-page outages
- Unexpected redirects or error responses
- Pages that load but no longer show the text you expect
Example URLs:
https://www.yoursite.comhttps://status.example.com
Pro Tip: You can use a Site monitor as a lightweight job alert. Point it at a company’s careers page, then add a Body Contains condition for the title you want, such as
design engineerorplatform engineer. When that text appears on the page, your monitor can alert you before you happen to check the site manually.
API Monitors
API monitors are for endpoints where uptime alone is not enough and you need to validate the actual response.
Use API monitoring when you need control over the request and want to confirm that the response body, headers, JSON fields, or latency still match your expectations.
How it works:
- Sends an HTTP request using your selected method
- Optionally includes auth, headers, query params, and a request body
- Validates the response using body text, JSONPath, headers, status code, and response-time conditions
In the current Add/Edit Monitor form, request customization lives in Advanced Request Settings. When you choose POST, PUT, or PATCH, the dashboard shows a helper below HTTP Method so you can jump straight to that section and add query parameters, request headers, and a raw request body.
Best for:
- REST APIs
- JSON health endpoints
- Authenticated health checks
- Webhooks and service-to-service endpoints
Helps you catch:
- APIs returning the wrong JSON even when they are still online
- Broken auth or missing headers
- Slow endpoints that are technically up but no longer healthy
Examples:
https://api.example.com/healthhttps://api.example.com/v1/statushttps://example.com/internal/ready
DNS Monitors
DNS monitors verify that a domain resolves the way it should.
They are useful when the main risk is not page rendering or API payloads, but whether traffic is being routed to the correct destination at all.
How it works:
- Queries DNS servers for your domain
- Checks if it returns the expected record
- Measures resolution time
Best for:
- Critical domains
- Detecting DNS hijacking
- Multi-region DNS setups
Helps you catch:
- Wrong DNS targets after provider changes
- Missing or broken mail-routing records
- DNS-level issues before they show up as website downtime
What it monitors:
- A/AAAA records (IP addresses)
- CNAME records
- MX records (email)
- TXT records
Not Yet Available in the Dashboard Form
You may see Database listed in the monitor-type selector as a future option.
- In Add Monitor, it appears as unavailable and cannot be selected.
- In Edit Monitor, an existing database monitor may still open for reference, but it is not editable from that dashboard form.
Treat it as a roadmap placeholder rather than an active dashboard workflow.
Validation Options Across Types
Site and API monitors both support richer validation than a simple “is it up” check.
That means you can monitor for the right outcome, not just any response. The careers-page job alert example above is one case: the page can stay online for weeks, but the monitor only becomes useful when your target text appears.
In the Add and Edit Monitor forms, valid Site and API URLs can also trigger a preview badge with status, response time, and content type. When the preview returns JSON, the dashboard can suggest JSONPath conditions to speed up setup.
- Status Code for exact codes or ranges
- Body Contains for text-based responses
- JSONPath for structured API payloads
- Header for response-header assertions
- Response Time for latency-based success rules
Guide: Advanced Expected Conditions
Need ideas you can copy? See Monitoring Configuration Examples.
Choosing the Right Type
Use this quick rule of thumb:
- Choose Site when you are checking a page or simple endpoint.
- Choose API when you need request customization or structured response validation.
- Choose DNS when you need to confirm a domain resolves to the correct record.
If you are comparing website monitoring types for a new service, start by asking what failure you care about most: page availability, API correctness, or DNS resolution.
| What You’re Monitoring | Recommended Type |
|---|---|
| Website homepage | Site |
| Marketing page | Site |
| API endpoint | API |
| JSON health endpoint | API |
| Domain DNS | DNS |
| Mail routing records | DNS |
Combining Monitor Types
For critical services, consider using multiple monitor types:
- Site monitor to confirm the website is reachable
- API monitor to validate your health endpoint returns the expected JSON
- DNS monitor to verify the domain still resolves correctly
This gives you broader coverage and makes it easier to pinpoint whether a problem starts at the DNS layer, the application layer, or inside the API response itself.