Setting Up Your First Monitor

What each setting does, how to choose the right values, and when the defaults are fine.

Creating a monitor takes about 60 seconds. You enter a URL, choose a few settings, and Monitoristic starts checking your site on a regular interval. When something breaks, you know within minutes — not hours.

This guide explains every field in the monitor form so you can make confident choices. For most sites, the defaults work well. Change them when you have a reason to.

The display label for your monitor. It appears in your dashboard, in alerts, and on status pages. Pick something your team would recognize at 3 AM when a Telegram alert wakes them up.

Good names describe what the endpoint is, not where it lives:

  • Good: Checkout API, Marketing Site, Admin Dashboard
  • Avoid: monitor-3, prod-us-east, test

The exact endpoint we send an HTTP request to on every check. This should be the public URL your users actually visit — not an internal IP, not localhost, not a VPN-gated address.

Always include the protocol:

  • https://example.com — correct
  • example.com — won't work

If you want to monitor a specific part of your site — like the checkout page or an API health endpoint — use that specific URL. Monitoring just the homepage might miss issues that only affect deeper pages.

The HTTP method used for each check. Three options:

  • GET — sends a full request and reads the response body. This is what a browser does when loading a page. The safe default for any website.
  • HEAD — sends a request but only reads the response headers, not the body. Faster and lighter. Use this for endpoints where you only care about availability, not the content — like large file downloads or media servers.
  • POST — sends a POST request. Use this for API endpoints that require POST (authentication endpoints, webhook receivers, form handlers). Most websites don't need this.

If you're not sure, leave it on GET. It works for the vast majority of websites and APIs.

The HTTP status code that means "this endpoint is working." The default is 200 (OK) — the standard success response for web pages and APIs.

If the response status doesn't match your expected status, the check is marked as down and an incident is created.

Monitoristic follows redirects automatically. If your URL returns a 301 or 302 redirect, we follow it to the final destination and check that status code instead. So you don't need to set 301 as the expected status for redirecting URLs.

When to change the default:

  • 204 — for API endpoints that return "No Content" on success
  • 401 — for auth-gated pages where you're testing reachability, not access
  • 403 — for endpoints that intentionally block unauthenticated requests

For most websites, 200 is correct. Don't change it unless you know your endpoint returns something different on purpose.

How often we check your endpoint, in minutes. The default is 15 minutes — a balanced starting point for most sites.

Your plan determines the minimum interval you can set:

  • Lite — minimum 5 minutes
  • Pro — minimum 2 minutes
  • Business — minimum 1 minute

The maximum interval on all plans is 60 minutes.

When to go lower

Lower intervals detect downtime faster. Use 1–5 minute intervals for:

  • Production APIs that process payments or transactions
  • Checkout pages where every minute of downtime costs revenue
  • Services your customers depend on (SaaS dashboards, client portals)

When the default is fine

15 minutes is fine for marketing sites, documentation, blogs, internal tools, and anything where a few extra minutes of detection time won't cause business impact. You'll still know about downtime well before your users start complaining.

How long we wait for a response before giving up and marking the check as down. Measured in seconds. The default is 30 seconds — deliberately generous to avoid false positives from momentary slowness.

Range: 5 seconds (minimum) to 60 seconds (maximum).

If a request times out, the check is recorded with a "Request timeout" error and the monitor is marked as down. An incident is created automatically.

When to lower it

APIs should respond in under 5 seconds. If your API takes 30 seconds to respond, it's functionally down for your users even though it eventually replies. Set the timeout to 10–15 seconds for APIs so that slow responses are caught as downtime.

When to raise it

Some legacy systems, report generators, or endpoints behind cold-start serverless functions legitimately take 30–45 seconds on the first request. Raise the timeout to 45–60 seconds to avoid false alarms.

The response time (in milliseconds) above which a check is flagged as "slow." The default is 1000ms (1 second) — the industry standard for web performance.

This is a performance signal, not a downtime alert. Slow responses show as amber in your dashboard and response time chart, helping you spot degradation before it becomes a full outage. The monitor stays "up" — it's just slower than expected.

Range: 100ms (minimum) to 30,000ms (maximum).

Recommended thresholds by endpoint type

  • Fast APIs (payment, auth, search): 300–500ms
  • Web applications (dashboards, SaaS): 800–1200ms
  • Content sites (blogs, marketing pages): 1500–2000ms
  • Heavy pages (reports, data-heavy dashboards): 3000–5000ms

If your dashboard is showing constant amber for a monitor, the threshold might be too tight for that endpoint. Raise it until amber means something worth investigating, not background noise.

After you create a monitor, it starts checking immediately. Here's what happens behind the scenes:

  • Every check records the HTTP status code, response time, and any errors
  • If a check fails (wrong status code or timeout), the monitor is marked as down
  • An incident is created automatically with a full timeline
  • If you've connected notification channels, you'll receive an alert instantly
  • When the next check succeeds, the monitor is marked as up and the incident is resolved
  • When a monitor is down, we check it every 60 seconds regardless of your interval — so recovery is detected quickly

To receive alerts, connect a notification channel:

What's the best check interval for my site? +
It depends on how critical the endpoint is. For payment pages and production APIs, use 1–2 minutes. For marketing sites and docs, 5–15 minutes is fine. Shorter intervals catch issues faster but use more of your monitor allocation.
What happens when a check times out? +
The check is marked as "down" with a "Request timeout" error. An incident is created and you'll receive an alert if you have notification channels connected. The monitor switches to 60-second accelerated checks until it recovers.
Should I use GET or HEAD? +
Use GET for most websites — it's what a browser does and gives you the most accurate picture of whether the page loads. Use HEAD only if you're monitoring a large file download or media endpoint where you don't need to read the response body.
What does the slow response threshold do? +
It flags checks where the response time exceeds your threshold as "slow" (shown in amber on your dashboard). This is a performance warning, not a downtime alert. The monitor stays "up" but you can see degradation trends before they become outages.