Getting started

SIP Sentry watches your SIP infrastructure from the outside: real OPTIONS, REGISTER, TLS, and DNS checks against your trunks, registrars, and SBCs, with alerting designed not to cry wolf.

1. Create your first monitor

Sign in, press New monitor, and pick a check type:

  • SIP OPTIONS — the default. Point it at your SBC or trunk endpoint, pick a transport (UDP, TCP, or TLS). Any SIP answer below 500 counts as alive; 5xx counts as down.
  • TLS certificate — point it at your SIP-over-TLS port (usually 5061). Set the SNI to your SIP domain, not the IP. You’ll be warned at 30, 14, and 7 days before expiry.
  • SIP REGISTER — create a dedicated test extension on your platform first (see REGISTER check safety), then give the monitor its credentials.
  • DNS SRV — point it at your SIP domain. It validates NAPTR (opt-in), SRV per service, and that every SRV target resolves.
  • Ping — ICMP latency and loss, with a transparent TCP fallback when ICMP is filtered.

2. Allowlist the probes (if your SBC filters SIP)

Good SBCs drop SIP from unknown sources. Two options:

  1. Allowlist our published cloud probe addresses, or
  2. Run a private probe inside your network — one container, outbound-only:
docker run -d \
  -e API_URL=wss://api.sipsentry.io/probe/v1/connect \
  -e PROBE_TOKEN=<token from the Probes page> \
  sipsentry/probe

If you can’t allowlist and your SBC drops unsolicited OPTIONS, set the monitor’s timeout behavior to degraded instead of down — that’s what the setting is for.

3. Route the alerts

Create channels under Alerting: email, signed webhooks, Slack, Telegram, or SMS. Then add rules: org-wide, per customer, or per monitor. Use the test button on every channel — an alert channel you’ve never tested is a channel that doesn’t exist.

4. Group monitors by customer

If you’re an MSP, create a customer per client and assign monitors to it. Each customer can get a public status page (/status/your-slug) with live states and 90 days of uptime — and per-customer alert routing, so the right engineer gets paged for the right client.

How alerting decides

  • A monitor goes down only after N consecutive failures (default 3) and recovers after M consecutive successes (default 2).
  • A timeout counts as down or degraded depending on your per-monitor setting.
  • If our probes lose coverage, monitors go unknown — which never fires customer alerts.

That’s it. Your first OPTIONS result lands within one check interval.