← Back to Dashboard
JAMSHelp Center

Recipients aren't getting SMS or calls

A flow fires, the dashboard says the notification was sent, but your phone doesn't buzz or ring. Here's how to debug it in order — most likely causes first.

1. Check the phone number on the User record

By far the most common cause: the phone number on the Team Member record is missing, wrong, or in the wrong format.

  1. Open Team Members.
  2. Click the recipient that should have received the alert.
  3. Look at the Phone field.

Requirements:

  • Must be in E.164 format — country code prefix + the rest of the number, no spaces, dashes, or parentheses. Examples:
    • ✅ +12025550123 (US)
    • ✅ +447700900123 (UK)
    • ❌ (202) 555-0123 — missing +, has formatting
    • ❌ 2025550123 — missing + and country code
    • ❌ 1-202-555-0123 — has dashes
  • No extension — extension fields aren't supported for outbound calls/SMS.
  • Real number, not voicemail-only — Twilio rejects some VOIP / fax / non-routable numbers.

Fix the format, save, then retrigger the alert.

2. For SMS specifically: check SMS opt-in status

This is the single most common reason SMS doesn't arrive while other channels do. JAMS Incident Management will not send SMS to a user who hasn't opted in (or who has replied STOP). The same alert's other channels — call, push, email — still fire; only SMS is held back.

Opt-in is self-service — the recipient controls it from their own Settings page under SMS Notification Preferences. There is no admin toggle on Team Members; you can't flip another user's consent for them.

To fix it, the recipient should either:

  • Open Settings, check I consent to receive SMS notifications, and save; or
  • Text START to the JAMS Incident Management phone number.

If they previously replied STOP (even on a different flow, or in another tenant), they're flagged opted-out everywhere until they re-opt-in by one of the methods above.

Important: never re-opt-in someone who said STOP without their explicit re-consent — that's a TCPA violation. Have the user opt themselves back in.

See Your Profile for the full walkthrough of where the SMS toggle lives.

3. For voice calls: check whether the number can receive calls

Some phone numbers technically work for SMS but not voice (or vice versa):

  • VOIP numbers (Google Voice, some online services) sometimes block automated calls
  • Carrier-blocked numbers — recipient's carrier flagged the source number as spam, drops the call before ringing
  • Number type mismatch — landlines can't receive SMS; mobile-only services may filter unknown callers

Test by:

  1. Going to Test Calling if your tenant has the page.
  2. Calling the recipient's number with a short test message.
  3. If the test call doesn't connect, the issue is with the number itself (carrier-level), not JAMS Incident Management.

4. Check the Notifications log

Open Notifications and find the recent attempt:

Status shownWhat it means
SentJAMS Incident Management successfully handed the message to the provider (Azure/Twilio). Delivery problems past this point are downstream — check the recipient's device.
FailedThe provider rejected it. Click for the error message. Common: "phone number not valid" (format issue), "carrier blocked," "rate limit."
QueuedStill in the worker queue. Should clear within seconds. If stuck for >1 minute, the worker may be paused — check with an admin.
Failed (quota exceeded)Your tenant used up its monthly SMS or voice allowance — the two are separate, so check which. Other channels are unaffected. See Billing.
AcknowledgedRecipient already acked. (Probably not the one you're looking at.)
CancelledA sibling notification in the same group was acknowledged, so this one was cancelled before sending.

5. Check the worker is actually delivering

If notifications are stuck in Queued state, the backend worker may be offline. Test the backend health endpoint:

curl https://<your-JAMS-backend-host>/health

Replace <your-JAMS-backend-host> with your backend's real hostname (shown on the Integrations page when you configure a webhook). It should return 200. If it's down or slow, contact support.

6. Check provider router state (admins only)

If you're a global admin, hit:

GET /api/admin/router-state

This shows the live state of each delivery provider (Twilio, Azure Communication Services). If a provider's circuit breaker is open, that channel is rerouting to the fallback — but if both providers are down, nothing delivers.

7. Tenant suspended?

If your account is past due or suspended, all outbound notifications get blocked. Check Billing for the current status. Suspended tenants are also unable to receive inbound webhooks.

8. Is the recipient deactivated?

A deactivated user is skipped during escalation — the flow doesn't pause for them, it moves straight to the next recipient. So if the person you expected to hear from was deactivated, that's why nothing reached them.

Open Team Members and confirm the recipient has a green "active" dot. If they were deactivated, flip Active back on, then retrigger.

9. Is the flow targeting an on-call rotation?

If the flow's recipient is an on-call rotation rather than a whole Team Group, JAMS Incident Management notifies only the person currently on call first — not everyone in the group. If that's not who you expected, it's working as designed.

Open On-Call Rotations, select the rotation, and check the "on call now" banner. If the wrong person is on call, fix the rotation order or add a schedule override. Only once the on-call person fails to acknowledge does JAMS Incident Management advance to the next member.

10. Less common: recipient's notification schedule

If you've set a notification schedule on the Team Member (e.g., "no alerts on weekends" or "only between 9am-5pm"), and the alert fires outside that window, JAMS Incident Management skips that recipient and moves to the next in escalation order.

Check the schedule on the Team Member profile. Either widen the window or remove the schedule if it's blocking legitimate alerts.

When all else fails

If you've worked through this list and still no luck:

  1. Note the Notification ID from the Notifications log.
  2. Note the recipient and the channel that failed.
  3. Note the rough time of the attempt.
  4. Contact JAMS Incident Management support with those three pieces of info. The audit log gives us enough to trace what happened end-to-end.

What's next