Allowing users to configure a timeout as low as 1 second doesn’t make practical sense. Before the actor’s code even starts running, the system performs internal tasks such as pulling the Docker image, initializing the container, etc., which can take several seconds. This means the actor can fail without even printing a simple Hello World. The failure happens immediately, leading to a poor user experience. On top of that, there’s no way for the developer to prevent this, since the user is the one setting the timeout.
These failed runs directly impact the “Runs succeeded” metric, which negatively affects the perceived quality and stability of the actor. While the ABORTED status exists for manual interruptions, here we’re dealing with automatic failures caused by misconfiguration, without even giving the process a chance to start properly.
In monetization models like Pay per Event (PPE) and Pay per Result (PPR), the cost of execution is often absorbed by the developer or the platform, depending on the user’s plan. Therefore, allowing such low timeouts is even more problematic. For example, a 1-second timeout might lead to no result being delivered at all, causing unnecessary costs with no real value. For this reason, it would be extremely helpful to enforce a minimum timeout — such as 10 or 20 seconds either directly from actor.json, the API, or the UI (ideally from all three), to protect both users and developers.
