rasa action server 500: custom action timeout

TL;DR

Rasa waits a fixed time for the action server's response, then returns a 500 and moves on. If your action does real work inline, slow cases exceed the wait. The fix is the same as every webhook timeout: keep actions fast, push slow work out, and raise the timeout only as a stopgap. A timeout increase without faster actions just moves the failure.

The query

rasa action server 500: custom action timeout

Use this when

• Custom actions fail with a 500 timeout
• Actions work for simple cases but fail for complex ones
• Action server logs show the work finishing after Rasa gave up

Not for

• Action server connection refused (not a timeout)
• Action name not found errors
• Rasa model or NLU loading failures

Steps

1. Find which actions are slow

Add timing logs to every custom action and correlate with the 500s. You'll usually find one or two actions doing multi-second work while the rest answer in milliseconds. Fix those; leave the fast ones alone.

Expected output: a list of actions with their p95 durations, slowest first.

2. Move slow work out of the action

For slow actions, return a holding message immediately and complete the work asynchronously, then send the result as a follow-up message. The action's job is to respond, not to finish the task.

Expected output: slow actions answering in well under the timeout.

3. Raise the timeout as a stopgap only

If a fix needs more time, raise Rasa's action timeout temporarily while you rework the action. Document it as temporary. A raised timeout with unchanged actions just makes failures slower and harder to debug.

Expected output: a documented temporary timeout increase with an expiry date.

4. Make retried actions idempotent

Rasa may retry or the user may repeat themselves, so a slow action can run twice. Guard side effects with idempotency keys so the second run is a no-op instead of a duplicate charge or ticket.

Expected output: no duplicate side effects from repeated action runs.

Variant phrasings

rasa custom action timeout increase

Step 3, with the warning attached: raise it, but fix the action.

rasa action server slow response 500

Steps 1 and 2: measure, then split the work.

Why it happens

The action server is a separate HTTP service, so every action is a network call with a deadline. Developers write actions like local functions, piling on database queries and API calls, and the happy path stays under the limit. The timeout only bites on the slow tail: big accounts, cold caches, flaky downstream services.

Edge cases

• Async action servers still block Rasa's wait. Async helps throughput, not the deadline.
• Health checks on the action server don't catch slow actions. Monitor action duration, not just uptime.
• Long-running actions also hold Rasa's conversation lock, blocking the user's next message.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstcrIpwITNYvpHocz7Rv1jw

Resolved from the public thread: https://vectle.com/posts/pstcrIpwITNYvpHocz7Rv1jw

Thread query: rasa action server 500: custom action timeout

TL;DR: Rasa waits a fixed time for the action server's response, then returns a 500 and moves on. If your action does real work inline, slow cases exceed the wait. The fix is the same as every webhook timeout: keep actions fast, push slow work out, and raise the timeout only as a stopgap. A timeout increase without faster actions just moves the failure.