# The greeting took seconds to arrive

The greeting is synthesised before the caller is picked up and played the instant they are, so a greeting that arrives seconds late was not in the answering process's cache and had to be made while the caller waited. Three things cause that: a process that has never warmed, a synthesis the model refused, and a greeting whose wording changed since the warm-up ran. The call record itself is unaffected.

- **Status:** Available
- **Audience:** both
- **Channels:** phone
- **In the app:** #/calls, #/phone
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/troubleshooting/greeting-too-slow/

## What it sounds like from the caller's side

The phone stops ringing, the line is clearly open — there is room tone, not a dead line — and then nothing is said for two or three seconds. Some callers say 'hello?' into that gap, which is worse than the gap itself, because the voice and the caller then start their first sentence at the same time.

This is a different fault from a voice that answers slowly once the conversation is under way. The greeting is pre-made audio; a reply is generated on demand. If the pause is *before* the first sentence, this page is the right one. If the greeting was instant and the pause comes after the caller's first question, read [the latency page](/docs/phone/latency/) instead — the floor there is the model's own first token, and 3.3 s was the median on the best call measured.

## Where the greeting is supposed to come from

Each call runs in its own process, and every idle process is given the chance to warm up before a call lands on it. Warm-up fetches the greetings a workspace's lines use, synthesises each one, and keeps the audio in that process under a key made of the workspace, the text-to-speech model, the voice, the style, the language and the greeting text itself. When the key matches, the greeting plays at pickup with no synthesis at all: measured, the inbound greeting went from three seconds to none.

A miss is not a failure. The process falls back to synthesising the line live, which is the pause you are hearing, and the warm-up hook never raises an error into the call. Every call records which of the two happened, so the question 'was this one warm?' has an answer on the call rather than a guess.

> **Note** Because the greeting text is part of the key, editing the greeting makes every already-warmed process cold for that line until it is replaced. A wording change and a run of slow greetings in the following minutes are the same event, not two.

## Causes, likeliest first

| Cause | What you would also see | How it clears |
|---|---|---|
| The greeting text, voice, style or language was changed recently | Slow greetings on that line only, starting at the change | Processes recycle and warm the new wording |
| The worker was deployed or restarted | Slow greetings across every line for a few minutes | Warm-up completes; later calls are instant |
| The text-to-speech model refused the warm-up synthesis | The warm-up counts a refusal rather than a failure | Warm-up retries with backoff when the refusal is one that passes |
| The call landed on a process that had no idle time to warm | One slow greeting with no pattern around it | Nothing to do; the next call on that process is warm |
| The line's language differs from the warmed entry | Slow greeting only on calls that open in that language | Warm the greeting for that language too |

The refusal case is worth understanding, because it used to be permanent. Every idle process asked for the same sentence with the same key in the same instant, the model's per-minute quota refused one of them, and that process gave up on its greeting for the rest of its life. Warm-up now staggers the processes, retries a refusal that is worth retrying — a rate limit or a server-side error, never a bad key — and counts refusals separately from failures so the two are not read as one number.

## What Connect completed

- The line was claimed and the call answered; a call record exists with its ring and answer times.
- The greeting was spoken in full, in the right voice and language — late, not missing.
- The conversation ran normally afterwards; the pause does not shorten anything that follows.
- The transcript, the outcome, the summary and any lead or follow-up were written as they would be on a fast call.
- The call's own record says whether the greeting came from the cache or from live synthesis.

## What Connect did not complete

- The greeting was not ready at pickup, so the caller heard an open line for the length of the synthesis.
- No warm cache entry was used for that call, and none was created retrospectively for it.
- Nothing was retried on the caller's behalf and nothing was said to cover the gap — no filler noise is played into a live line.
- If the greeting could not be spoken at all, that is a different outcome entirely and the call ends rather than sitting silent; see [the silent-call page](/docs/troubleshooting/call-answered-in-silence/).

## What you can do

1. Open the call and check whether the greeting was warm or live.
   - Result: A live synthesis explains the pause and ends the investigation. A warm greeting with a slow start is a different fault.
2. Check whether the greeting wording, voice or language was edited in the hour before the calls you are looking at.
   - Result: If it was, the slow greetings should stop by themselves as processes recycle onto the new key.
3. Look at the next few calls on the same line.
   - Result: One slow greeting is a cold process. A run of them is a restart, a refusal or an edit — the table above separates the three.
4. Keep the greeting short. It is one sentence of audio, and a long one takes longer to make on a miss.
   - Result: A shorter greeting narrows the worst case without changing the warm case, which is already instant.

## What an administrator can do

**Check the instruction budget** — Greeting delay and reply delay are separate, but both grow with prompt size. Measured on the same stack, a 7,500-character instruction gave a first token in 1.2–1.8 s and 9,600 characters gave 2.3–3.4 s. The knowledge, memory and contact budgets — 4 facts and 2,000 characters, 700 characters, 600 characters — exist for that reason.
**Check the voice model** — The default realtime model reaches first audio in about 0.6 s; the older native-audio model is 1.2–2.2 s. Choosing the older one for its mid-call abilities is a deliberate trade, not a fault.
**Watch refusals, not just failures** — A greeting quota refusal is transient and retried. A refusal that repeats on a key that never succeeds is a configuration problem with the voice or the language, not load.
**Give warm-up room** — Warm-up runs inside process start-up and has its own time budget, larger than the default start-up bound. A worker being killed and restarted faster than it can warm will never produce a warm greeting.

## When to escalate

Escalate when every call on a line is slow to greet for longer than the few minutes a restart explains, when refusals keep being counted against a greeting that never succeeds, or when the greeting stops being spoken at all rather than being late. The last of those is not a slow greeting: a line that cannot be spoken ends the call and records that it did, and five inbound calls once sat in silence and were written down as callers who hung up before speaking. That misattribution is why the engine now records a silent failure by name.

## Questions

### Does the caller hear silence or a dead line?

An open line. The call is answered, the audio path is up and the pause is the time the greeting audio takes to be made. Nothing is played into the gap deliberately, because a filler noise on a business line reads worse than a short pause.

### Will changing the greeting text make calls slow?

Briefly, on that line. The greeting's own text is part of the cache key, so every warmed process holds audio for the old wording and has to make the new one live until it recycles. Plan wording changes for a quiet period if the line is busy.

### Can I pre-warm on demand before a campaign?

Warm-up is tied to idle worker processes rather than exposed as a button. In practice the way to be warm is to leave the wording alone for a while before the busy period, and to avoid a deploy immediately before it.

## Related

- [The greeting](https://connectbyjbrh.com/docs/phone/greeting/)
- [Greeting warm-up](https://connectbyjbrh.com/docs/phone/greeting-prewarm/)
- [Reply latency on a call](https://connectbyjbrh.com/docs/phone/latency/)
- [The voice worker](https://connectbyjbrh.com/docs/phone/voice-worker/)
- [What every character of a prompt costs on a live call](https://connectbyjbrh.com/research/prompt-size-and-first-token/)
- [The call connected and nobody spoke](https://connectbyjbrh.com/docs/troubleshooting/call-answered-in-silence/)

## What this page is based on

- `docs-source/sources/PHONE.md` §8 — greeting warm-up
- `docs-source/sources/PHONE.md` §7 — the model and instruction size
- Connect capability registry (docs-source/facts.py) — MEASURED