RanchAlerts
Sign In Request Access

Product

Infrastructure monitoring that matches how you work

A monitor is a named thing you care about — a website, a mail host, a nightly job. Each monitor uses one or more checks. Checks run on a schedule from a city you pick. Alerts go to contacts and to Slack, Discord, Teams, or a webhook — not to everyone with a login.

HTTP

The usual starting point for a website or health URL. RanchAlerts issues an HTTPS GET from a polling city and expects a successful response. Include https:// or we add it.

  • Optional “page must contain” text in the first 64 KB. Missing text is treated as down.
  • Redirects are followed only after each hop is validated.
  • Alert if slower than a threshold marks the monitor Slow and sends a warning. The site stays Up for uptime and public status pages.
  • Certificate expiry is a warning. A handshake failure is an outage.

PING

Ask a hostname or IP if it answers ICMP. Use this when you care that the host is reachable, not that a particular page loads.

A PING failure does not mark a sibling HTTP or port check down. You can put several methods on the same named monitor and read them separately.

Port Monitoring

Open a TCP connection to a port. Typical uses: HTTPS (443), SMTP (25 or 587), IMAP (143 or 993), FTP (21), SSH (22), DNS (53).

RanchAlerts only checks that the port accepts a connection. It does not log in or speak the application protocol. That keeps the check honest and keeps us out of your mailboxes.

Heartbeats

Most monitors reach out to you. A heartbeat works the other way: your scheduled job visits a unique HTTPS URL on push.ranchalerts.com. If the visit is late, the monitor is down.

Use this for cron, Task Scheduler, backups, and workers with no public port. Treat the push URL as a secret. Only ping after the work succeeded. Heartbeats are a package option.

DNS Records

Look up a name from our cities and confirm the answer still includes the values you listed. Extra records are allowed. Matching ignores letter case and a trailing dot.

This is not the same as port 53. Port monitoring asks whether something accepts a TCP connection. A DNS monitor reads A, AAAA, CNAME, MX, TXT, or NS contents. DNS is a package option.

Registered Domains

Watch the name itself: nameservers and registration expiry. RanchAlerts does not read WHOIS contact details.

  • A nameserver add, drop, or replace is a change alert. The monitor stays Up and the new set becomes the baseline.
  • Expiry warnings at 30, 14, 7, and 1 days. Those are not a Down incident. You still renew at the registrar.
  • Down is reserved for a failed nameserver lookup.

When it fails

Thresholds. A check has a failure count before it is down, and a success count before it recovers. Defaults are conservative. Intervals are capped by your package.

Confirmation. When three or more cities are healthy, a down waits until two other healthy cities also fail. If only one peer is live, that one remote failure still confirms.

Maintenance. Schedule a window when you already know the circuit is coming down. Alerting pauses. Checks still run. You can exclude the window from uptime.

After a confirmed outage, RanchAlerts records ping and path diagnostics from the cities that saw the failure. Heartbeats skip this because they have no outbound target.

People

Contacts get alerts. A contact is a name and a verified email, with an optional mobile number. Contacts do not get a RanchAlerts login. Saving a number requires consent — that is how SMS is attached. On each monitor you choose Email, SMS, or Email and SMS per contact. Saving a number does not turn texts on by itself.

Team members sign in. Owners, administrators, members, and read-only users share an organization. Members can run monitors. They cannot manage membership. Read-only can look, not change. Inviting a teammate also adds their email as a contact so new monitors can alert them. Authenticator MFA is required at activation.

Integrations

Chat rooms and automation tools are destinations, not people. Under Settings → Integrations you paste an incoming webhook URL. New destinations notify every monitor unless you turn that off and assign them on Who Should We Alert.

  • Slack — Incoming webhook on hooks.slack.com.
  • Discord — Channel webhook on discord.com.
  • Microsoft Teams — Incoming webhook on webhook.office.com.
  • HTTPS webhook — Any public HTTPS endpoint. RanchAlerts posts signed JSON with X-RanchAlerts-Signature so PagerDuty, n8n, or your own receiver can verify the source.

URLs are stored encrypted and are not shown again after save. Only public internet destinations are accepted. A failed chat or webhook delivery does not block email or SMS. Quiet hours skip texts only.

REST API and hosted MCP

Owners and administrators issue keys under Settings → API. The secret starts with ra_live_ and is shown once. A read key lists data. A write key can create, edit, pause, and delete monitors and schedule maintenance. Portal cookies are not accepted.

  • REST — https://api.ranchalerts.com/v1/ with Authorization: Bearer. OpenAPI is at /v1/openapi.json.
  • MCP — https://mcp.ranchalerts.com/mcp for Cursor, Claude, and other agents. Paste the same key. A read key only sees list and get tools.

Targets stay on the public Internet. The API uses the same checks as the portal. Signed-in customers have a written guide under Help → API & MCP.

Service packages

Each organization has a service package. A package sets the fastest check interval, how many monitors, contacts, team members, integrations, and API keys you can have, and whether SMS, heartbeats, DNS, and domain monitors are included. SMS has a calendar-month cap.

We are currently in beta testing and will be open for public access in Q4/2026. If you already have an invitation, sign in at the portal. If you do not, request access.