Call log

The leg log under Voice > Legs lists each connection your workspace placed or received, newest first. A call can contain several legs, such as the incoming and forwarded connections. Each entry is a call detail record (CDR), including connections that rang out or were refused. Use it to inspect duration, the final SIP response, and cost.

Bird writes each record when the leg ends, so each entry in the log has a final outcome. The Live tab beside it holds the legs that are still up.

For the complete interaction, open Voice > Calls. A call groups related legs and participants. Keep the Call ID for correlation and the Leg ID when investigating one connection; they identify different records.

The call list

Each row is one leg. A call with multiple legs has multiple rows:

The list is paginated, 25 legs per page. Select any row to open the leg record.

Live calls

The Live tab lists the legs up right now, and carries a count so you can see how many are up without opening it. A live leg holds one of two statuses:

The columns match the leg log except for Elapsed, which replaces Duration. It counts from the answer for a connected leg and from the start for a ringing leg. The tab refreshes every few seconds. When a leg ends, it moves to the leg log with its final outcome.

Searching and filtering

The page leads with a number search and its filters. They combine: a status filter plus a date range narrows to the legs matching both.

Search by number. The search box matches a number against either side of the leg, so one query finds the legs to it and the legs from it.

Direction. Filter to outbound or inbound legs.

Status. Filter to one of answered, no answer, failed, rejected, or unknown. Each is defined in Statuses. On the Live tab the choices are ringing and in progress.

Date. On the call log, pick a preset (the last 24 hours, 7 days, or 30 days) or choose a custom range on the calendar.

Usage this month

The monthly summary contains three tiles for the current calendar month in UTC:

The difference between total duration and billable time is unanswered ring time. An unanswered leg has no billable time.

Each destination rate rounds billable time to its billing increment. See Cost and billing for pricing details.

These tiles cover the whole month whatever you filter the list to.

Statuses

A leg in the log ended with one of these outcomes:

Rejected covers two refusals, and the rejection reason separates them. Either Bird refused the call before a carrier was involved, in which case the reason names the check it failed, or the far end declined it outright, in which case SIP response carries its answer and there is no reason. An incoming call that the number it dialed turned away is Rejected with no reason too, because it failed no check: its Inbound route says what the number was set to do. See Rejected calls.

Failed is not a refusal. It means the call was attempted and did not work: a busy number is Failed with carrier response 486, and an unallocated one is Failed with 404.

If you read these values from your own tooling, match the ones you handle and treat any other as a status you do not handle rather than an error. The list also carries busy and canceled, reserved for incoming calls delivered to your own numbers. Neither is emitted yet, and both outcomes are reported as failed today.

Inspecting a call

Opening a leg shows what Bird recorded about that connection:

Inbound route appears on incoming calls and records the selected route. A trunk route on a rejected call means the call did not reach a working answer. Receiving calls explains the routes and what each one records.

Rejected calls

A rejected call was refused rather than carried through, and two different things produce that.

Bird refused it before a carrier was involved. Before dialing out, Bird checks the caller ID, destination, account limits, and wallet balance, and refuses a call that fails one of them. Your phone system receives SIP 503, while the authenticated call record stores the specific reason. This prevents unauthenticated callers from learning account details. Open the call to see the cause and a link to the relevant setting.

The number that was dialed turned the call away. An incoming call to a number set to reject, or to a number nobody has pointed anywhere, is rejected with no reason at all: it failed no check of ours. Inbound route is what says so. Receiving calls works through those refusals.

The reasons below are the first kind. They apply to incoming calls as well as outgoing ones, because the account limits and the wallet are checked either way.

Reasons you can fix

A campaign dialer can hit calls_per_second_exceeded while nowhere near the concurrent-call ceiling, so check which of the two you got before changing anything.

Reasons Bird resolves for you

These sit on Bird's side of the setup. Contact support and quote the Leg ID from the record:

How a refusal reads

Read the status and the rejection reason together:

• Rejected with a rejection reason. Bird refused the call, and the reason identifies the failed check. The SIP response is the 503 your phone system received. Follow the reason's account or routing resolution.
• Rejected with no rejection reason. On an outgoing call, the far end declined it outright and SIP response carries its code. On an incoming call, the number that was dialed turned it away, and Inbound route says what that number was set to do.
• Failed. The call was attempted and did not work, and SIP response contains the code that came back. A 486 means busy, while 404 means the number is unallocated. This usually points at the number rather than at your setup.

A call Bird cannot admit at all is turned away before a record exists, so it never reaches the log. Voice troubleshooting covers those calls.

Getting the records out

Four ways to work with these records outside the dashboard:

• Export CSV. Download CSV on the Leg log tab exports the records matching your current filters across pages, up to 10,000 legs. A larger selection returns an error without a file; narrow your date range or filters and export each selection separately. Use it for reconciliation and ad-hoc reporting.
• Read them over the API. GET /v1/voice/legs returns the filtered list, and GET /v1/voice/legs/{leg_id} returns one record. Both require an API key with the voice scope at read level. Check the API reference for the published operations for other Voice resources and their required scopes.
• Read them from the terminal. The Bird CLI provides bird voice legs list, bird voice legs get, and bird voice stats. The MCP server exposes the same reads to agents.
• Subscribe to the events. voice_call.initiated, voice_call.answered, and voice_call.ended are pushed to your endpoint as calls happen, so your own systems stay current without polling. See Voice events.

Next steps