Before you create the monitor
Choose a route or service that represents real user impact. A homepage monitor is useful, but it does not prove that login, checkout, an API dependency, or a webhook path works. Start with one monitor for each business-critical path.
Step-by-step
- Sign in and open the dashboard.
- Select New Monitor.
- Enter a clear monitor name, such as "production API health" or "checkout HTTPS".
- Choose the monitor type: HTTPS, HTTP, TCP, or ping.
- Enter the target URL, hostname, or port depending on the monitor type.
- Choose the check interval that matches the route's importance.
- Save the monitor and wait for the first check result.
Naming matters during incidents
Use names that point responders toward the owner and route. "Website" is too broad. "www homepage HTTPS" is better. "api checkout health endpoint" is better still because it tells the team where to look first.
Choose an interval
A 5-minute interval is a practical default for most public pages. Use shorter intervals for routes where a few minutes of missed downtime changes support load, revenue, or customer trust. The uptime SLA calculator can help convert reliability targets into downtime budgets before you choose.
After the first check
Confirm the monitor status, response time, and recent history. If the first result is down, verify the target from another network before treating it as an application outage. Typos, blocked monitor IPs, and redirects to login pages are common first-run issues.
For public websites, prefer HTTPS checks with SSL validation. For backend services, use TCP checks only when the monitoring location is authorized to reach that port.