Monitoring

What monitoring covers

Monitoring is the operational layer above call logs and post-call analysis. Call logs tell you what happened on one call. Monitoring tells you whether the system as a whole is behaving, and when to intervene.

Three signal families matter in practice:

Latency

The platform latency target is under 800ms from end-of-user-speech to start-of-Finn-response. That target holds at 1 concurrent call and at 1,000 concurrent calls. Per-call latency is recorded in the telemetry section of the per-call drill-in view, alongside ASR confidence, voicemail detection result, and hangup cause.

Four things move latency in the wrong direction, and none of them are load:

The burst spike is the one that surprises people. If you launch a large campaign cold, the first handful of callers get the worst experience of the run. Place a few scheduled test calls before the real spike to pre-warm.

Regional latency is not fixable after the fact. Region is chosen at account creation and cannot be changed without a data migration. See data-residency.

Answer rate and completion rate

Completion rate is the percentage of attempted calls that reached a real human and got through the conversation, as opposed to no-answer, busy, or voicemail. It is the answer-rate metric on the platform.

The important discipline: completion rate is a list metric, not an agent metric. If completion is low but success among completed calls is fine, your list or your calling hours are the problem. Rewriting the prompt will not move it. Success rate is the agent metric, and it is computed against your primary success field from post-call-analysis.

Both numbers are unstable early. While a deployment is live, success rate is computed against calls completed so far and moves as more calls finish. Wait for the deployment to complete, or for at least 100 calls, before you act on either number.

Average duration is the cheapest quality proxy you have:

What to alert on

There is no alert-rule builder in the API. Alerting is built from the webhook stream and your own systems. Configure the endpoint under webhooks and subscribe to completed-call events, then evaluate thresholds on your side. Slack alerts for deployment failures are a documented step in the scale-up path, wired the same way.

Alert on these, in priority order:

1. Deployment failure. Highest signal, lowest volume. A failed deployment stops producing calls entirely, so the absence of events is itself the alarm. Alert on no completed-call events for a live deployment over a window you choose.
2. Webhook delivery failure. If your endpoint is down, every downstream metric you compute is silently wrong. See webhook-retries.
3. Completion rate drop against your own baseline. Finn does not publish a threshold here. Establish your own from a healthy run, then alert on deviation.
4. Latency outliers. Alert on the tail, not the mean. Aggregates hide the calls that failed.
5. 429 Too Many Requests. Rate-limited responses carry a Retry-After header. Sustained 429s mean your integration needs backoff, not a plan upgrade. See api-rate-limits.
6. Concurrency ceiling. Outbound calls queue rather than fail when you exceed the limit. Inbound calls get a busy tone or fallback voicemail. The dashboard shows a yellow warning banner in both cases. Occasional is fine. Repeated means upgrade. See concurrency.

Item 6 is the one that fails quietly. Queued outbound calls do not error, so nothing in your logs looks wrong. Your campaign just takes longer than planned and you find out from the banner rather than from an alert.

Reading the dashboard

Live Deployments shows real-time call counts, an active call table, and a health panel. That panel is the first stop when a deployment underperforms: check whether anything is red, whether the buffer drained, whether the dispatcher errored.

Aggregates are cached. A Cached badge appears when the number you are reading came from cache. Click Refresh to force a recompute.

The one-minute summary TTL means a dashboard number can lag a webhook event you already received. When they disagree, the webhook stream is the fresher source. Build alerting on the stream and use the dashboard to investigate, not the reverse.