@Lukas Krivka Sorry for tagging you, but
@Lukas Krivka Sorry for tagging you, but I’ve been trying for a while to find a way to enforce a minimum timeout from actor.json, the API, or even from the UI. I’ve thoroughly searched the official API documentation, the actor.json file, but I haven’t found any option that would allow me to enforce or validate a minimum execution time. I’m aware that a default value exists, but users can freely override it and, for example, set extremely low values like 1 second which leads to a number of issues that I’ll explain below.
4 Replies
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.
Yeah, we are aware of this but so far no user abused/misused it yet, did it happen to you? We will probably implement this in the future
Ah, I see I thought there might be a way to change that value, either in the actor definition or during execution by modifying the timeout via the API.
While an official validation is not yet in place, the only workaround I can think of is to add logic at the very beginning of the actor to check whether the configured timeout is too low (e.g., less than 5 seconds). If it is, the actor could simply print a message explaining that the timeout is too short for proper execution and then exit immediately while marking the run as successful. This way, the “Runs succeeded” metric wouldn’t be negatively impacted, and the user would be clearly informed of the issue.
However, if the user sets the timeout to something as low as 1 second, there’s a high chance the platform will hit the timeout before the actor’s code even starts running. Tasks like pulling the image and initializing the container can already take several seconds. In that case, I wouldn’t even have a chance to run my custom check or log a message the run would fail instantly.
Yeah, I was talking this to the team few times already but so far I'm not aware that someone would consistently abuse this. In general, Apify is already complicated so we only add new config if they solve a real world problem