How RanchAlerts supports your team

Every check result stores the city that ran it. You pick a primary city per monitor. Today we poll from:

If a city’s own path is degraded, scheduled checks temporarily run from the next closest healthy location without changing the preference you saved. A degraded city is not used to confirm someone else’s outage.

Firewall and WAF operators can copy current egress IPv4 addresses without a login: Monitoring IPs.

A problem in one city is not automatically your outage. When several locations are healthy, RanchAlerts asks other cities to try the same check before we open a down incident and notify you.

• Confirmation runs immediately, in parallel, from healthy peers.
• If only one other healthy city remains, that remote failure still confirms.
• You see which cities agreed — not a black box.

One open outage per monitor. Further failures attach to that incident instead of sending another wave of mail. Reminders follow the interval your organization sets, then continue on a predictable cadence while it stays down.

Recovery closes the incident and sends one recovery message. Maintenance windows pause customer down, recovery, and reminder mail for the scoped monitor so a planned fiber cut is not treated as a surprise.

RanchAlerts is built to watch internet-facing websites, hosts, ports, DNS, domains, and scheduled jobs — the infrastructure partners and customers actually use. Private office networks and cloud metadata endpoints are not valid targets.

Before we connect, we resolve the name and check the addresses. Redirects are validated hop by hop. A failed PING does not mark a sibling HTTP or port check down, so you can watch reachability and the application separately.

We request the URL you give us and judge success by the response. You can require a phrase on the page, set a slow-site threshold, and treat certificate expiry as a warning instead of a fake outage. Timeouts and response size are capped so a hung origin does not stall the rest of your checks.

Backups, exports, and workers can visit a unique HTTPS URL on push.ranchalerts.com. Silence means the job did not finish. Treat that URL as a secret, and only ping after the work succeeded.

People join by invitation and set their own password. Sessions stay on the server, rotate at login, and can be signed out on every device. Authenticator MFA is required.

Organization roles are owner, administrator, member, and read-only. The current organization comes from the signed-in session. Customer data stays isolated between organizations.

Email is always available and uses verified contacts. SMS is a package option with consent, a monthly cap, and quiet hours that skip texts while email still sends. If an outage is still open when quiet hours end, held texts go out then.

Contacts receive alerts. Team members sign in. They are not the same list, which keeps a status-page subscriber or an on-call phone from accidentally becoming a portal login.

Paste an incoming webhook URL under Settings → Integrations. Slack, Discord, and Microsoft Teams post into the channel you already use. A generic HTTPS webhook receives signed JSON so tools like PagerDuty or n8n can verify the source.

Destinations are not people. They sit next to contacts on Who Should We Alert. New integrations notify every monitor by default. Quiet hours do not skip chat or webhooks. A failed delivery does not block email or SMS.

Automation uses hashed organization keys, not portal cookies and not iOS login tokens. Settings → API is where owners and administrators create, rotate, and revoke them. The raw secret is shown once.

REST lives at https://api.ranchalerts.com/v1/. Streamable HTTP MCP lives at https://mcp.ranchalerts.com/mcp. Both sit on the same app host. Tools call the same services as the portal, including public-Internet target checks. A read key cannot change monitors.