Call Action history

What it is

Every time your chatbot tries to use a Call Action, Agentency records a run: what the chatbot passed, what came back, how long it took, and how it ended. The Run log is where you read those runs.

It is the debugging surface for actions. You should never need server logs, and you will never see a stack trace — failures are reported as plain, client-safe reasons like Blocked destination or Upstream error.

When you would use it

• A visitor says "nothing happened" after the chatbot promised to do something.
• You just enabled an action and want to confirm it is firing.
• The success rate on an action card dropped and you want to know why.
• Your team stopped receiving handoff or notify emails.
• An integration worked for months and suddenly stopped — usually an expired credential, and the run log names it.

Where to find it

Open Dashboard → Chatbots → your chatbot → Actions, then select View logs on the action's card. The Run log opens as a drawer over the library.

Steps

1. Open the Actions tab.
2. Find the action's card and select View logs.
3. Read the status on each row first — it tells you which stage the run reached.
4. Use Status and Date to narrow down. The status filter and date range search every run; the search box only looks at the page you are on, and says so.
5. Open Details on a row to see the Arguments the chatbot extracted, the Request summary, and the Response summary.
6. Fix the cause — usually the description, the credential, or the address.
7. Re-test from the action's Test tab, then trigger it again from Test Chatbot and confirm a fresh Success row.

Reading the statuses

Status	What actually happened
Success	The action completed. For an email action the message was handed to the mail server; for an API action the endpoint answered.
Failed	It reached a terminal failure. Open Details and read the error reason.
Timed out	The endpoint did not answer within the per-call budget, or a queued delivery never reported back and the watchdog settled it.
Awaiting confirmation	The chatbot asked the visitor to confirm and is waiting. This is normal for actions that change data.
Pending	A queued side effect — a handoff or notify email — is in flight. It should settle within moments.
Skipped	A confirmation was never answered. The visitor was asked to confirm, did not, and the run was eventually retired.

Skipped is specifically an abandoned confirmation, not a catch-all. If an action never ran because it was disabled, or because the model chose something else, there is no run row at all — an empty log means the action was never attempted.

Skipped runs count as neither a success nor a failure, so an abandoned confirmation does not drag your success rate down.

Error reasons you may see

Reason	Usual cause
Invalid arguments	The chatbot could not produce a value your parameters require. Improve the parameter descriptions.
Misconfigured action	Something in the action's own configuration is wrong — most often a malformed URL.
Blocked destination	The address is private, internal, or otherwise not reachable from the public internet.
Timed out	Your endpoint was too slow.
Upstream error	The other service answered with an error. Usually credentials, scopes, or a rejected payload.
Unreachable	The host could not be contacted at all — DNS, or the service is down.
Temporarily paused	The same endpoint failed repeatedly, so calls to it were briefly suspended rather than retried into the ground. It resumes on its own.
Rate limited	A per-visitor, per-chatbot, or per-minute ceiling was reached, or the identical request was already in flight.
Delivery failed	An email destination could not be reached — check the address on a handoff or notify action.
MCP error	An MCP server call failed. See MCP connector availability.

What you will see

The drawer lists runs newest first, with the status, when it ran, and how long it took. Filters sit at the top:

• Status — one of the six statuses, or all.
• Date — Today, Last 7 days, Last 30 days, Last 90 days, or All time. Dates are interpreted in your own timezone, so "Today" means your today. See Timezones and rollups.
• Search — matches arguments, response, and error text on the current page only. The hint under the box says so, and the result count tells you how many matched.

Open Details on any row for three panels: Arguments (what the chatbot extracted from the conversation), Request (a summary — method, host, status code), and Response (a truncated snippet). Long results are paginated.

Secrets never appear in any of it. The request summary shows the host and status, not your credential, and no header values are printed.

How the counters relate

The four numbers at the top of the Actions tab — Actions, Enabled, Total runs, Success rate — and the per-card counts come from these same runs.

Success rate is the share of runs that finished with Success, across all of that action's runs since it was created. It is a lifetime figure, not a rolling window, so a run of bad days early on keeps weighing on it after you fix the cause. Judge a recent fix by filtering the log to the last 7 days rather than by watching the headline percentage move.

Runs still awaiting confirmation, and skipped ones, are not counted as failures.

What history will not do

• It will not replay a run. There is no re-fire button, deliberately: replaying would send a second email or create a second order. Use the Test tab for a dry run instead — it contacts nothing.
• It is not a workspace-wide audit export. History is per action, per chatbot, and read in the dashboard.
• It does not keep runs forever. Runs are subject to your deployment's data-retention settings. Do not treat the run log as your permanent record of what a customer asked for; the conversation transcript is the better source for that. See Read a conversation.
• It does not show sandbox tests. Test-tab runs record nothing at all, by design.

Limits and plan notes

• The run log is available on every plan that can have actions at all — which excludes Free, since Free includes no enabled actions. See Plans and what you get.
• You need permission to manage actions on that chatbot to open it. See Roles and permissions.
• Arguments captured on a Collect info run can contain personal data the visitor typed. Treat the run log as a place customer data legitimately lives, and use the Customers tools when you need to honour a deletion request. See Anonymize a customer.

Common problems

There are no runs at all.

The chatbot has never attempted this action. Either it is disabled, the chatbot's model does not support tool calling, or no visitor question has matched the description. Use the Test tab with a realistic sentence to find out which. See Create a Call Action.

Every run says Blocked destination.

The address points somewhere private or internal, or a placeholder was left in it. Use a public HTTPS address you control. See HTTP connectors.

Runs sit at Awaiting confirmation and never complete.

Visitors are being asked to confirm and are not replying. Either the confirmation is not warranted — turn Requires confirmation off for a read-only action — or your prompt is landing at an awkward moment. Note that any action that changes data requires confirmation regardless of the switch.

A run says Success but nothing arrived.

For email actions, Success means the message was accepted for delivery. Check the destination mailbox's spam folder and its filters.

Success rate looks wrong.

It is lifetime, not recent. Filter the log by date to judge current behaviour.

I need older runs than the log shows.

Retention is set per deployment. If you need a longer record, export what matters as it happens rather than relying on the log.