The follow-up went out at the wrong time
A due time on a follow-up is the earliest moment it may run, not an appointment. The drain reaches due rows on a tick and takes phone follow-ups two at a time, approval can add hours, an unready line adds about one, and the hour a reader sees depends on which clock they are reading. Compare the due time on the row with the timeline entry before you change anything.
The symptom, stated precisely#
Somebody received a message or a call from Connect at an hour that reads as odd — late in the evening, early in the morning, or simply not the time written on the commitment. The follow-up itself completed normally and the outcome is recorded, which is why this reads as a timing fault rather than a failure.
Two different complaints hide under the same sentence, and they have different fixes. Either the row's due time was never what you thought it was, or it was right and the send happened later. The row and the timeline together tell you which: the due time is on the follow-up, the timestamp of what actually happened is on the person's timeline, and the gap between the two is the thing to explain.
What a due time promises#
It promises *not before*. The drain runs on a scheduler tick and picks up rows that have come due since the last one, so a follow-up due at the top of an hour goes out on the first tick after that, never before it. Phone follow-ups are drained two per tick on purpose, so a backlog of five due calls is spread across ticks rather than dialled at once.
| Delay | Typical size | Visible where |
|---|---|---|
| The tick interval | The gap to the next scheduler pass | The timeline entry sits a little after the due time |
| Two phone rows per tick | Grows with the size of the backlog | Several due calls going out in sequence, not together |
| Held for approval | However long the queue waits | Needs You, with awaiting approval on the row |
| The line or mailbox was not ready | About an hour, then retried | A refusal on the row followed by a later success |
Which clock the hour is in#
A follow-up stores an instant. The wording you typed when you created it — a date, a time, or a phrase like 'next Tuesday' — was resolved to that instant once, at the point of scheduling, and editing the phrase later means editing the row rather than re-typing the words. If the person you are chasing keeps a different working day from the workspace, the instant can be exactly right and the local hour still wrong.
How instants are represented and returned to a client is documented for integrators on Time in the API. For calls, the guard that stops Connect ringing outside working hours is business hours on the line, and it is a property of the line rather than of the follow-up.
What Connect did complete#
- The commitment was executed with its reason intact and on the channel it named.
- The provider acknowledged the message or the call, which is why it appears on the timeline at all.
- The follow-up was closed with the outcome that actually happened, timestamped when it happened.
- The due time on the row was never rewritten by the delay; the record still shows what was promised and what was delivered.
What Connect did not complete#
- It did not hold the message back to a nicer hour on a messaging channel. A due follow-up on a text channel runs when it is reached.
- It did not translate the due instant into the recipient's working day. That instant is the instruction it was given.
- It did not warn anybody at scheduling time that the moment chosen was unusual — the check happens at execution, not when you type.
- No second attempt was made at a better hour; one commitment produces one execution.
What you can do#
Put the row's due time next to the timeline entry.
Result A small gap is the tick and the queue. A large gap points at approval or a retry, both of which are named on the row.
If the due time itself was wrong, edit the follow-up rather than cancelling and retyping the phrase.
Result The reason, the person and the history stay attached; only the timing changes.
For a chase that must land inside somebody's working day, schedule it inside that day rather than relying on a guard to move it.
Result The commitment says what you meant, and the record reads honestly to whoever inherits it.
Administrators and escalation#
An administrator can look at whether approval is the delay — a channel held for approval turns every due follow-up into a queue-waiting time — and at line health, since the hour-long retry only appears on a channel that keeps going unready. Both are settings, not defects.
Escalate when the gap between due and delivered cannot be explained by any of the four delays, when rows execute *before* they are due, or when the same commitment runs more than once. Give the follow-up, its due time and the timeline entry; those three facts are the whole investigation.
Questions#
Is the due time an appointment?
No. It is the earliest moment the follow-up may run. The drain reaches it on the next scheduler tick, and phone rows are taken two per tick, so a busy queue spreads calls out rather than firing them together.
Can Connect delay a message to a more polite hour by itself?
Not on the strength of the follow-up alone. Working-hours protection lives on the phone line, not on the commitment, so a message channel runs when it is reached. Schedule inside the hours you want if the hour matters.
The message arrived two days after it was due. How?
A phone follow-up cannot: past 24 hours late it is closed as missed. Two days means a second commitment was created, most often by a merge bringing another record's follow-ups onto the surviving person.