Error Handling and Retries

Every call ends with an outcome. Some outcomes are business signals you decide how to act on, for example retrying a customer who didn't answer. Others are connection or system issues that the platform detects and handles for you automatically, so you don't have to build cadences around them.

This page explains the difference, so you can focus your campaign configuration on the outcomes that actually need your attention.

Two kinds of outcomes

How the two campaign types handle this

Outcomes you can build cadences around

In Pulse, you group customer outcomes and route each group to the next step (a wait, a redial, an SMS, or an exit). The most common built-in groups are:

You can also route any of your own custom dispositions (for example, sales or retention outcomes) to their own next steps.

What the platform handles automatically

You do not need to create redial steps for these; they are managed for you:

• Temporary connection or system issues: a call that fails to place because of a transient carrier, network, or infrastructure problem gets one initial execution plus up to 3 technical retries. The retries are delayed by 5 minutes, then 10 minutes, then 20 minutes. Every retry is scheduled inside your compliant calling hours (see Calling hours and compliance below). If all 3 retries fail, the contact is recorded as an action failure after technical retries and is not retried further.
• Carrier declines / blocks: handled the same way as system issues, with one initial execution plus up to 3 technical retries. Because outbound caller IDs rotate, a retry can go out on a different number or route, so a block on one execution does not necessarily block the next. If every execution is declined, the contact exits with the reason recorded.
• Permanently unreachable numbers: disconnected, unallocated, or out-of-service numbers are stopped immediately (no retry), because calling again would never succeed.
• Agent-first: no agent before dialing: the customer stays queued until capacity is available. No call is placed, so this is a hold rather than an attempt or technical retry.
• Agent-first: no agent after a live dial-first answer: this is an abandonment, not a connection error. careCycle plays the required message, records Abandoned, and returns the customer to pending without routing that execution through Pulse.
• Agent-first callback: no agent accepts: because callbacks are accept-first, the customer is not dialed. careCycle records No Agent Available for the internal call record and re-arms the callback while its window remains open.

The kinds of issues in each group

At a high level, these are the reasons the platform detects and handles for you:

You will not see the raw internal error labels for these in your reporting; they roll up to the plain-language reasons above.

If a contact is ultimately removed from a campaign for one of these reasons, it's recorded with a plain-language reason (for example, "Number is disconnected or unreachable" or "Action could not be completed") so you can see why.

Calling hours and compliance

Every call (a first attempt, a cadence redial, or an automatic system retry) is placed only when it is allowed:

• Business hours: calls go out only during your organization's configured business hours, which respect holidays and any special-hours overrides.
• TCPA hours: regardless of your business hours, no call is ever placed outside 8:00 AM to 9:00 PM in the customer's local time zone (based on the customer's location). This is enforced for you and cannot be bypassed by a cadence.
• Automatic deferral: if any attempt (including an automatic system retry) would land outside these hours, it is automatically moved to the next compliant time rather than dialed early or skipped. So a system error late in the evening is retried the next morning. This deferral is a hold, not another execution or technical retry.

Because of this, the timing of a retry is always the later of "when the cadence/retry says" and "when it's compliant to call."

Controlling how many times a customer is tried

Your Pulse cadence is the control for how often and how long to keep trying a customer who has not been reached. Explicit outcome paths, Wait nodes, and Loop nodes determine whether another call or message happens. For example, a loop of "call, wait 1 day, repeat, up to 4 iterations" creates four spaced call attempts. There is no active campaign-level 15-attempt ceiling.

Technical retries are separate from cadence iterations. Each transient action failure gets one initial execution plus up to 3 technical retries after 5, 10, and 20 minutes. A permanent failure stops immediately. Waiting for compliant hours, waiting for calling capacity, and waiting for an agent before dialing are holds or deferrals. They do not create another cadence attempt or consume a technical retry. An Agent-first abandonment happens only after a live customer has answered; it is recorded separately and the customer returns to pending without advancing Pulse.

Historical campaign records can still show "Reached the maximum attempts." That outcome reflects the previous campaign-level limit and does not mean a current campaign has an active maximum-attempts setting.

How SIP codes map to outcomes (technical reference)

For the technically inclined: when an outbound call fails before or during connection, the carrier terminates the leg with a SIP response code. We classify every carrier-terminated leg with a single classifier, so the same code always produces the same outcome, and the raw code is preserved on the call record (as carrier_rejected_<code>) for diagnosis.

The codes fall into four classes:

Expected non-connects (the recipient's side)

These codes describe the person or their line not being reachable right now. They are normal telephony outcomes, so they map to the No Contact dispositions and follow your cadence (redial, SMS, or exit), exactly like any other no-contact call:

These are "expected" because a dial that rings out or hits a busy line is part of normal outreach; treating them as errors would inflate error rates and hide real problems.

Carrier declines and blocks (auto-retried, never routed to your cadence)

These codes mean a carrier refused to complete the call: typically spam filtering, caller-reputation scoring, or policy. The enrollment stays in your Pulse, and the platform makes one initial execution plus up to 3 technical retries after 5, 10, and 20 minutes. This is worth doing because a block is usually a decision about the specific caller ID or route used on that execution; outbound numbers rotate, so a retry can go out differently and succeed.

What these outcomes never do is route through your disposition branches: a blocked attempt isn't a customer signal, so your cadence doesn't see it. If every attempt is declined, the enrollment exits with the reason recorded, and the raw code stays on the call record:

Note the 487 split: the same code means different things depending on whether the call actually rang. A 487 after real ringing is a recipient no-answer (your cadence handles it); a 487 with no ring progress is a carrier decline.

Dead numbers (stopped immediately)

Calling again can never succeed, so the contact is stopped with a plain-language reason and never retried.

System errors (retried automatically)

Anything indicating a fault on our side, in the network path, or a transient infrastructure problem gets the automatic retry treatment described above (one initial execution plus up to 3 technical retries after 5, 10, and 20 minutes):

The codes above are the complete set observed in production. SIP defines many more failure codes that carriers could in principle return; if a call ever ends with one we have not seen before, it defaults to this same system-error treatment (retried automatically), so no code can fall through unhandled.

A note on 1xx codes (100, 180, 183)

You may also see calls whose last SIP status is a provisional code: 100 Trying, 180 Ringing, or 183 Session Progress. Provisional codes mean the leg died without ever receiving a final response (for example, the audio bridge dropped mid-setup). Those calls are classified as system errors through the connection-failure path above.