> ## Documentation Index > Fetch the complete documentation index at: https://docs.usetuner.ai/llms.txt > Use this file to discover all available pages before exploring further. # Run statuses > What each simulation run status and call result means, how to fix Unreported and Analysis failed, and how simulated calls are linked to a run. A simulation run reports a status for the run and a result for each call. This page lists every value and how to fix runs that don't complete. ## Where runs appear Every simulation run appears as a card on the **Runs** tab of **Simulations**. The card header shows when the run started, what it ran (for example "7 routine · 3 pressure", or "5 from library", plus the language, test profile and environment), a counts line and a status badge. Click the card to expand it. An expanded run card on the Runs tab: the counts line "3 passed · 7 failed", the Complete badge, and the per-call table with result icons, Type, Evals, Outcome, Intent and duration ## Run status | Status | Badge | What it means | | - | - | - | | **Generating** | Blue, spinner | Tuner is writing the Scenarios for this run. | | **Pending** | Blue, spinner | The Scenarios are ready and the calls haven't started. | | **Running** | Blue, pulsing dot | Calls are in progress. A run whose calls have all ended stays **Running** until the first call reaches Tuner from your agent. | | **Analyzing** | Blue, spinner | Every call has ended. Tuner is still waiting for at least one call to arrive from your agent or for its evals. | | **Complete** | Green | Every call ran and was analyzed. Check the counts line for how many passed. | | **Partial** | Amber | Some calls didn't run, went **Unreported** or hit **Analysis failed**, and the rest were analyzed (or the problems were of more than one kind). | | **Failed** | Red | No call was analyzed and every call failed to run, or the run itself failed. Expand the card to see the reason. | | **Unreported** | Amber, unplugged-cable icon | Every call ran, but none of them arrived from your agent. See [Fix an Unreported run](#fix-an-unreported-run). | | **Analysis failed** | Red, clipboard-with-X icon | Every call arrived, but evals couldn't be completed for any of them. See [Fix Analysis failed](#fix-analysis-failed). | Only **Unreported** and **Analysis failed** show a tooltip when you hover the badge. It says what went wrong and what to check, as in the fix sections below. ## Call results Expand a run to see one row per call, with the columns **#**, **Type** (**Routine** or **Pressure**), **Evals**, **Outcome**, **Intent** and **Dur.** The icon at the start of each row shows the call's result: | Result | Icon | What it means | | - | - | - | | **Passed** | Green check | A Routine call passes when none of its Pass/Fail evals failed. A Pressure call with a target eval passes or fails on that eval alone. | | **Failed** | Red X | An eval that decides the result failed, or the call didn't run. | | **Unreported** | Amber, unplugged-cable icon | The call ran, but no matching call arrived from your agent within 15 minutes. | | **Analysis failed** | Red, clipboard-with-X icon | The call arrived, but its evals didn't come back within 10 minutes. Results that arrive later are still scored. | | **Ran** | Green check | The call ran in a run with no evals to grade, for example a replay with no Pass/Fail evals selected. | | **Pending** | Gray clock, dashed circle | The call hasn't started or is still in progress. | | **Evaluating** | Blue spinner | The call ended and Tuner is analyzing it. | Hover an **Unreported** or **Analysis failed** icon for the same tooltip as on the run badge. Hovering a **Ran** check shows "Ran — no evals were expected for this run". The other icons have no tooltip. A call whose outcome has [**Stop Analysis**](/docs/evaluation/call-classification) turned on counts as done and shows **Passed**, since Tuner skips its evals. Once Tuner has received a call, click its row to open the [call details](/docs/observability/call-logs). On the **Scenarios** tab and on a Scenario's page, the same results show as **Passed**, **Failed**, **Unreported**, **Analysis failed** or **Pending**. ## Counts line The counts line next to the badge sums up the calls, for example "6 passed · 2 failed · 2 remaining". It can show: | Count | What it counts | | - | - | | **passed** and **failed** | Calls with a result. | | **ran** | Calls that ran in a run with no evals to grade. | | **remaining** | Calls still pending or being evaluated, while the run is **Pending**, **Running** or **Analyzing**. | | **not run** | Once the run has settled, calls that didn't run. | | **unreported** and **analysis failed** | Calls flagged with those results. These show as soon as a call is flagged, even while the rest of the run is still going. | ## Fix an Unreported run **Unreported** means Tuner placed the call but never received a matching call from your agent's integration. Open **Call Logs** and look for the call. Tuner couldn't match it to the simulation. Check that your integration sends back the value Tuner links on. See [How simulated calls are linked](#how-simulated-calls-are-linked). Check that your integration is sending calls to Tuner. ### The Call-ID may arrive under a different name This is the most common cause of **Unreported** inbound calls on LiveKit, Pipecat and custom stacks. When Tuner dials your agent, it sends a standard SIP `INVITE` that contains a `Call-ID` header: ``` INVITE sip:your-agent@provider.example SIP/2.0 Call-ID: 2jf9wCCXfwgxKkTOfLcEsA5LD6f ... ``` Your SIP provider receives this `INVITE`, accepts the call, and captures that `Call-ID`. It then surfaces the value to your application, which passes it back to Tuner. SIP is a standard, but every provider wraps it in their own platform. By the time the call reaches your application code, the original `Call-ID` header may have been renamed, nested inside a larger object, or even dropped entirely unless you opt in to forwarding it. Here are some real-world examples of how this happens: * **Renamed field**: A provider receives the SIP `Call-ID` but exposes it to your app as `SipCallId`, `sip_call_id`, or `call_id`. The value is the same, but the key is different from the original SIP header name. * **Nested inside metadata**: Instead of a top-level field, the `Call-ID` may appear inside a nested object like `sip.headers["Call-ID"]` or within a `custom_headers` list that you need to iterate through. * **Not forwarded by default**: Some providers split the call into two legs: an HTTP webhook (which receives SIP context) and a WebSocket (which carries the audio). The SIP fields may only be available on the webhook side, and you need to explicitly configure your webhook response to forward them to the WebSocket as custom parameters. * **Replaced with a provider-native ID**: If the provider does not forward the SIP `Call-ID` at all, your app may only see the provider's own internal identifier (e.g. a `CallSid`, `call_control_id`, or `call_sid`). This is **not** the same as the original SIP `Call-ID` that Tuner sent, and simulation linking will not work unless you configure forwarding. * **Regenerated across hops**: If the call passes through multiple SIP intermediaries (for example a SIP bridge, then a PBX, then your provider), each hop may generate its own `Call-ID`. In these cases, look for a correlation header like `X-CID` that carries the original value across all hops. **Don't assume the original `Call-ID` will be there.** Check your provider's documentation for how SIP headers are surfaced to your application, and verify that the value you're sending back to Tuner matches the one Tuner originally sent. When in doubt, capture a test call and inspect the raw payload your application receives. If the value is lost, the call still arrives in Tuner, but as production traffic, and the simulated call shows **Unreported** in the run. ## Fix Analysis failed **Analysis failed** means the call arrived but its evals couldn't be completed. Run the Scenario again. If it keeps happening, contact support. ## How simulated calls are linked Tuner links each call your integration sends back to the simulated call it placed. A call that isn't linked is still ingested, but it appears as production traffic and the simulated call shows as **Unreported**. | Agent | Tuner links on | Where to set it | | - | - | - | | Inbound (LiveKit, Pipecat, Custom stack) | The SIP Call-ID of the call Tuner placed, sent back as `sip_call_id` | [LiveKit](/docs/integrations/livekit#enable-simulation), [Pipecat](/docs/integrations/pipecat#enable-simulation), [Custom stack](/docs/integrations/custom-stack/sdk-quickstart#enable-simulation) | | Outbound (LiveKit, Pipecat, Custom stack) | The `recipient`: the SIP URI Tuner gave your trigger endpoint, sent back exactly as received | [LiveKit](/docs/integrations/livekit#enable-simulation), [Pipecat](/docs/integrations/pipecat#enable-simulation), [Custom stack](/docs/integrations/custom-stack/sdk-quickstart#enable-simulation) | | Retell and Vapi | Tuner links these calls itself | Nothing to set | If the ID is lost in transit, the run shows **Unreported**. Some telephony providers rename or drop the SIP Call-ID before it reaches your application. See [The Call-ID may arrive under a different name](#the-call-id-may-arrive-under-a-different-name). ## Next steps Save Scenarios from a run and rerun them to check a fix. Open a simulated call's details once it reaches Tuner. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.