I built the same automation in n8n, Make, and Zapier. One died on the free tier.

This reporter constructed three identical automations using n8n, Make, and Zapier. However, only one of them completed successfully. The reason for this discrepancy was due to a free tier limitation on Zapier. The Zapier free tier has a runtime cap of one second for a Code step, which was insufficient for the automation's required transformation.

My task was to compare the three platforms, and the task's simplicity lay in reading a CSV from a URL, filtering and transforming the rows, and writing the results out. The key detail, however, was that the transformation needed a real code step. This specific requirement turned out to be the core of the story as it was not widely emphasized in most comparisons.

Zapier's free tier imposes a one-second limit on Code steps, which meant that the job would never run, regardless of how well the code was written. This highlights a fundamental difference between Zapier and the other two platforms. On Zapier's free tier, the runtime limitation was a hard stop, and the outcome was determined before the automation was even built.

In contrast, Make got stuck in the builder during the construction of the job, causing a delay in completing the scenario. Lastly, n8n, self-hosted, ran the same job without any runtime limits, completing the automation successfully. It is essential to note that self-hosted n8n has no runtime cap because it is the host, but it does require additional costs such as server maintenance, updates, and the responsibility of troubleshooting issues, even if they occur during off-hours.

The main takeaway from this experiment is that the runtime limits on code steps should be the first thing checked when evaluating these tools, rather than being the last consideration.