Google Apps Script vs Make for Google Sheets Automations: Quotas, Triggers and When Free Breaks

Most small-business automation starts and ends in a Google Sheet. New form responses need tidying. New rows need to become invoices, Slack messages or calendar events. A weekly report needs to land in someone’s inbox every Monday. Sooner or later, someone has to choose between writing a little code and dragging boxes around a canvas.

For Sheets work, the two options that come up most are Google Apps Script, the free scripting platform built into Google Workspace, and Make, the visual automation tool formerly known as Integromat. I have built the same Sheets automations in both, watched which ones broke, and seen the bill when a “small” Make scenario turned out to run every few minutes. Here is how they compare when the spreadsheet is the centre of the work.

Code inside Google or boxes across apps

If the automation lives mostly inside Google, such as Sheets to Gmail, Sheets to Calendar or Forms to Sheets, and someone on the team can read a little JavaScript, use Apps Script. It is free, it runs right next to your data, and it can do almost anything inside Google.

If the automation connects Sheets to many outside apps, or the people maintaining it do not write code, use Make. It has ready-made connectors for thousands of services, clear run history, and visual error handling. Watch how often it runs, though, because that is what you pay for.

Scripts next to your data, scenarios across services

Google Apps Script is JavaScript that runs on Google’s servers with built-in access to Sheets, Docs, Gmail, Drive, Calendar and Forms. You can attach a script to a spreadsheet or run it standalone. Scripts run on triggers: when a sheet is edited, when a form is submitted, on a timer, or when you run them by hand. It costs nothing beyond your Google account, but it has quotas, and you write and maintain code.

Make is a visual automation platform. You build “scenarios” by connecting modules on a canvas: watch a Google Sheet for new rows, filter them, look something up in another app, and send the result somewhere else. It has connectors for thousands of apps, branching and error-handling tools, and a detailed history of every run. Pricing is based on operations: each module that runs uses one, and plans include a monthly allowance. Make has been renaming operations to credits, but the idea is the same.

Triggers: how each one knows to run

For Sheets automation, the trigger is where the two differ most in practice.

Apps Script has triggers built into Google itself. An “on form submit” trigger fires the moment a Google Form response lands in the sheet. An “on edit” trigger fires when someone changes a cell by hand. A time-driven trigger runs on a schedule, every hour, every day or every week. These are efficient: nothing polls, and nothing costs money. Two catches. First, time-driven triggers fire within a window rather than at an exact minute: a “daily at 9” trigger runs sometime between 9 and 10. Second, edit triggers fire for edits made by people, not for changes made by other scripts or by imports.

Make has two kinds of trigger. Instant triggers use webhooks: another app tells Make the moment something happens. For Google Sheets, though, the common “watch rows” trigger polls: Make checks the sheet every so often for new rows. Each check counts as an operation, even when there is nothing new. That makes polling the hidden cost of Sheets scenarios in Make.

Cost: free with quotas versus paying per run

Apps Script is free, but not unlimited. Google sets quotas that are generous for most small teams but real: a single run is limited to about six minutes, total trigger runtime per day is capped, and there are daily limits on emails sent, external web requests and similar actions. Workspace accounts get higher limits than personal Gmail accounts. Most Sheets automations never come close. The ones that do are usually processing thousands of rows in one run, and the fix is to process in batches.

Make’s cost depends on how often a scenario runs and how many modules each run uses. The arithmetic catches people out. A scenario that polls a sheet every 15 minutes runs 96 times a day, around 2,900 times a month, before it processes a single row. Add a few modules for each new row, multiply by your volume, and a “simple” scenario can outgrow a free plan, and some cheap paid plans, quickly. Shortening the polling interval for faster reactions multiplies the cost again.

Ways to keep Make affordable for Sheets work:

• Poll less often. Many “new row” automations are fine running hourly or daily.
• Use an instant trigger where possible, for example a Google Form or another app sending a webhook directly to Make instead of Make watching the sheet.
• Filter early, so rows you will ignore stop at the first step instead of running every module.
• Process rows in bulk with aggregator modules rather than one at a time.

If you are comparing Make with other paid tools on cost, the same reasoning applies across platforms, and the numbers are laid out in what the same workflows cost in a year on n8n, Zapier and Make.

What each one does well

Apps Script is best when the work is inside Google. Formatting and cleaning form responses, generating a Google Doc or PDF from a row, sending personalised emails from a list, creating calendar events, building custom menus and buttons in the sheet, or adding custom spreadsheet functions. Because the script runs next to the data, it can read and write thousands of cells in one call, which is far faster than processing row by row through an outside service.

Make is best when the work crosses apps. New row in Sheets, create a contact in the CRM, post to Slack, add a task in the project tool, update the row with the new IDs. Each of those apps has a ready-made Make module, authentication is handled for you, and you never touch an API document. Building the same flow in Apps Script means writing HTTP requests against each service’s API and handling authentication and errors yourself. It is possible, but it is real development work.

For a direct comparison with another popular paid tool, Apps Script vs Zapier covers where free code beats paid automation, and most of that reasoning applies to Make too.

When things break

Every automation fails eventually: an API changes, someone renames a column, or a row arrives with a blank where a value should be. How you find out, and how you fix it, matters as much as how you built it.

Make is strong here. Every run is recorded, and you can open it to see exactly what data entered and left each module. Error handlers let you route failures to a different path, retry, skip, or alert someone. When a scenario fails repeatedly, Make can stop it and notify you. For non-developers, that visibility is a big part of the value.

Apps Script gives you an execution log and error emails, but debugging means reading code and adding your own logging. A common silent failure catches many people: if a time-driven trigger keeps failing, Google can disable it, and the notification email is easy to miss. The script then simply stops running, and nobody notices until the report does not arrive. It is worth knowing why Google disables Apps Script triggers and checking your triggers occasionally.

The column-rename problem hits both. Make scenarios often map spreadsheet columns by position or header, and Apps Script code usually reads specific columns. Rename or insert a column and either one can quietly write data to the wrong place. Protect the header row, or look up columns by header name in your scripts.

Who will maintain it in a year

This question is often more important than any feature.

An Apps Script automation is code. If the person who wrote it leaves, someone else needs to read JavaScript to change it. Well-written, commented scripts are easy to hand over; clever, undocumented ones become untouchable. Scripts also belong to a Google account. If that account is deleted, its triggers and scripts can stop, so attach important scripts to a shared spreadsheet owned by a long-lived account.

A Make scenario is visible. Anyone with access can open the canvas and see what happens, in order. That makes Make automations easier to hand over to non-developers. The risk is the opposite: because anyone can change a scenario, an unreviewed change can break it. Use Make’s version history, and keep a short note of what each scenario is for.

Matching the tool to the spreadsheet

Apps Script is the better fit when:

• The automation stays mostly inside Google: Sheets, Forms, Gmail, Docs, Drive and Calendar.
• Someone on the team can read and maintain JavaScript.
• It processes many rows at once, or runs often, where per-run pricing would add up.
• You want custom menus, buttons or functions inside the spreadsheet.
• Budget is zero.

Make is the better fit when:

• The automation connects Sheets to several outside apps.
• The people maintaining it do not write code.
• You want detailed run history and visual error handling.
• Volume is modest, or you can use instant triggers instead of frequent polling.

Plenty of teams end up using both: Apps Script for the heavy lifting inside Google, and Make for the handoffs to everything else, often with the script calling a Make webhook when it finishes. That split keeps the expensive part of Make small, and keeps the code limited to what code does best.