Treat carrier_rejected as a category, not a diagnosis
Some messaging systems normalize several downstream failures into a status such as carrier_rejected. The label tells you the message crossed at least part of the provider path and was not accepted for delivery downstream. It does not prove whether the cause was content, sender registration, destination validity, carrier policy, routing, or a provider translation.
Preserve the raw provider code and description beside your normalized status. If your integration throws that detail away, every different rejection becomes the same unhelpful incident.
Stabilize before you retry
- Stop unbounded retries for the affected cohort while leaving healthy traffic alone.
- Confirm whether the alert is based on final delivery events or an application-side timeout.
- Measure the failure rate against the same country, carrier, sender, and use case from a healthy baseline.
- Identify the first failed message and the last known successful message.
- List configuration, template, sender, routing, deployment, and volume changes between those two timestamps.
- Give users a safe fallback for security-critical flows rather than asking them to request the same SMS repeatedly.
Slice the failures until one boundary appears
| Dimension | Question |
|---|---|
| Country | Is this one destination market or a global rejection? |
| Carrier | Do recipients on one network fail while control networks deliver? |
| Sender | Did one originator lose registration, association, or route compatibility? |
| Template | Did wording, links, encoding, or segment count change? |
| Use case | Are OTPs healthy while alerts or promotional traffic fail? |
| Time | Was the change abrupt, gradual, or limited to a sending window? |
The smallest repeatable cohort is your working incident scope. Keep testing controlled: opted-in numbers, low volume, and one changed variable per attempt.
Send a useful escalation, then monitor the boundary
- Three or more message IDs with UTC timestamps and raw downstream errors.
- Destination country and carrier, sender type and identifier, route if exposed, and exact template version.
- Consent and opt-out state without unnecessary personal data.
- A concise test matrix showing what delivered and what failed.
- The first failure time, last success time, traffic volume, and any relevant configuration change.
- A direct question: which downstream stage rejected the message and what action is required?
While the escalation is open, alert on the affected cohort rather than total SMS volume. A global metric can recover because traffic shifts even though the original carrier boundary is still broken.
Make the next incident page answerable
The best incident tool is a message timeline that already contains the identifiers support will ask for. Normalized statuses are useful for product logic; raw provider evidence is essential for debugging.
Keep the raw delivery trail
Notilify keeps transactional SMS metadata and delivery events connected so carrier rejection incidents start with evidence instead of log archaeology.
Try Notilify