What monitoring covers
Call logs tell you what happened on one call. Monitoring is watching a deployment while it runs and knowing when to step in. Finn gives you a live view of each deployment in the dashboard and a webhook per call. There are no built-in alerts: you build those on your side from the webhook.
The Live Deployments page
Open a running deployment to see it update as calls happen. A banner shows whether live updates are connected. If the connection drops, the page falls back to polling.
| Card | What it shows |
|---|---|
| Call counts | Calls so far, split into completed and failed. |
| Active calls | Calls currently initiated, ringing or in progress. |
| Success rate | Completed calls ÷ calls dialled. A connection measure, not whether calls met their goal. See metrics. |
| Avg duration | Average duration of completed calls. |
Below the cards, the Call History table lists each call with its time, duration, call status, end reason, voicemail field, Finn number and user number. Refresh reloads it.
From the header you can Pause, Resume or Stop the deployment.
Reading it
| What you see | What it usually means |
|---|---|
| Mostly failed calls | A number or carrier problem: the calls aren't being placed or are being rejected. See spam labeling and troubleshooting. |
| Many calls, few completed | People aren't picking up. A list or number problem, not an agent problem. |
| Completed calls with very short durations | People hang up on the opening. Check the welcome message. |
| Completed calls running very long | The agent isn't closing. Tighten the prompt's end conditions. See agents-prompting. |
| Status Paused when you didn't pause | Deployments pause when the workspace's credits run low. Top up and resume. See api-wallet. |
| No new calls on a running outbound deployment | The audience may be used up. Check the planned and completed counts in the header. |
Rates are computed over the calls made so far, so they move a lot early on. Wait for at least 100 calls before you act on a rate.
Deployment data in other dashboard pages can be up to 5 minutes old. When the dashboard and a webhook you just received disagree, the webhook is the fresher source.
Alerting from the webhook
Point a webhook endpoint at your own system under Settings → Integrations → Webhooks. Finn sends one call.completed event per call, usually within about 5 minutes of the call ending. See webhooks and webhook-post-call.
Things worth alerting on, in priority order:
- No events from a deployment you expect to be calling. A stopped or paused deployment produces nothing, so silence is the signal. Alert when a live deployment sends no events for a window you choose.
- A jump in failed calls. Count
statusvalues per deployment and alert when the share offailedmoves well above your normal. - A drop in connected calls. Track the share of
completedagainst your own baseline from a healthy run. Finn doesn't publish a threshold. - Analysis answers you act on. For example
call_successful = falseon a high-value list, or a Yes/No question likewants_callbackturningtrue. - Your own webhook failures. Finn tries each delivery 3 times and doesn't redeliver after that. Watch Deliveries for the endpoint, and reconcile gaps with
GET /calls/{call_uuid}. See webhook retries. 429responses from the API. They carry aRetry-Afterheader. Sustained 429s mean your integration needs backoff. See api-rate-limits.
Related
- Metrics: what each number counts.
- Call outcomes: reading why calls ended.
- Concurrency: how many calls run at once.