Why does Logger.log not show anything when I run my script?

Logger.log output does not appear on screen during execution. After the run finishes, open View > Logs in the script editor (Ctrl+Enter / Cmd+Enter) to see the output. If you ran from a trigger rather than manually from the editor, go to the Executions panel in the left sidebar instead — View > Logs only shows the most recent manual run.

How long do Apps Script logs stay in the Executions panel?

Approximately 14 days from the time of execution. After that they are deleted automatically and cannot be recovered. If you need longer retention, write important debug output to a Sheet or a log Sheet tab during the run itself.

Can I see logs in real time, or do I have to wait for the function to finish?

console.log streams to the Executions panel in near-real-time, so you can watch it update while the function is still running. Logger.log is batched and only appears after the execution completes. For long-running functions, use console.log inside loops and Logger.log for one-time entry or exit markers.

What is the difference between the Executions panel and View > Logs?

View > Logs shows only the Logger.log output from the single most recent manual run in the current editor session — it has no history. The Executions panel (clock icon in the left sidebar) shows every run across all triggers and manual executions for the past 14 days, with full log output and error traces expandable per row. Always use the Executions panel for anything beyond the immediately preceding run.

// Apps Script

View logs and debug an Apps Script (where Logger.log actually goes).

Logger.log in Apps Script does not print to any console you can see while the script runs. Here is where to find the output, why console.log behaves differently, and how to read the Executions panel before the logs expire.

“I ran Logger.log in my Apps Script but I cannot find the output anywhere — no popup appeared, no console opened, and I do not know where to look.”

The script

copy · paste · trigger

debug_example.gs

Apps Script

// Run this from the editor to see where Logger and console output land
function debugLoggingDemo() {
  var sheet = SpreadsheetApp.getActiveSpreadsheet().getActiveSheet();
  var lastRow = sheet.getLastRow();

  Logger.log('Sheet name: ' + sheet.getName());
  Logger.log('Last row with data: ' + lastRow);

  for (var i = 1; i <= lastRow; i++) {
    var cell = sheet.getRange(i, 1).getValue();
    if (cell === '') {
      Logger.log('Empty cell found at row: ' + i);
      continue;
    }
    console.log('Row ' + i + ' value: ' + cell);
  }

  Logger.log('Done. Rows scanned: ' + lastRow);
}

Generate yours

Need a variant? Gnaw writes a custom version from one sentence — fields, triggers, edge cases handled.

Walkthrough

Where the output actually lands

Logger.log does not open a popup, does not write to your browser's DevTools console, and does not appear anywhere on screen while the function runs. Every call accumulates in memory for the duration of that execution, then gets flushed to the Apps Script backend log store when the function returns.

To read those logs after a manual run from the editor, go to View > Logs (keyboard shortcut Ctrl+Enter on Windows, Cmd+Enter on Mac). That dialog shows the full Logger output from the most recent execution only — close it and run again, and the previous run's output is gone from that view.

The more durable place is the Executions panel: in the left sidebar of the script editor, click the clock icon labeled Executions. Every run appears there with a timestamp, trigger type, duration, and status. Click any row to expand it and see the full log output for that run. Logs persist in the Executions panel for roughly 14 days, which is the only window you have before they expire permanently.

Logger.log vs console.log — they are not the same

Both write to the Executions panel, so in practice you can use either and find the output in the same place. The difference is visibility timing: Logger.log output only appears after the execution completes, batched. console.log output streams in near-real-time in the Executions panel, which makes it more useful when you are watching a long-running function and want to see progress before it finishes.

The first time I hit this distinction, I had a loop over 500 rows and Logger.log gave me nothing until the whole function returned — by which point I had already killed it. Switching to console.log inside the loop let me watch rows tick by and spot the row causing the hang. That is the practical difference worth remembering.

One quirk: Logger.log accepts a format string with printf-style substitution — Logger.log('Value is %s and count is %d', myVal, count) — while console.log does not support that syntax in Apps Script the way it does in Node. Use string concatenation with console.log to stay safe.

Debugging scripts triggered by a schedule or form

When a script runs from a time-driven trigger or a form submission trigger, there is no editor session attached, so View > Logs shows nothing. The Executions panel is the only way to see what happened. Navigate there, filter by function name if you have several, and expand the row for the relevant trigger run.

If the run shows status Failed, the Executions panel includes the error message and stack trace alongside the log output — you do not need a separate error handler just to find out what went wrong. For quota errors specifically, the message will reference the service name (e.g., SpreadsheetApp, MailApp) and the error class Exception or GoogleJsonResponseException.

One gap to know about: if your trigger function calls a helper function and the helper throws, the stack trace names both functions in order. Apps Script does not give you line-level stepping in triggered runs, so dense Logger.log calls at checkpoints — entry, mid-loop, exit — are the practical substitute for a debugger in those contexts.

Want a custom version?

Describe your sheet and the rule you want. Gnaw writes the Apps Script — fields, triggers, edge cases — in one shot.

Generate yours Browse BullPack

FAQ

4 questions

Why does Logger.log not show anything when I run my script?: Logger.log output does not appear on screen during execution. After the run finishes, open View > Logs in the script editor (Ctrl+Enter / Cmd+Enter) to see the output. If you ran from a trigger rather than manually from the editor, go to the Executions panel in the left sidebar instead — View > Logs only shows the most recent manual run.
How long do Apps Script logs stay in the Executions panel?: Approximately 14 days from the time of execution. After that they are deleted automatically and cannot be recovered. If you need longer retention, write important debug output to a Sheet or a log Sheet tab during the run itself.
Can I see logs in real time, or do I have to wait for the function to finish?: console.log streams to the Executions panel in near-real-time, so you can watch it update while the function is still running. Logger.log is batched and only appears after the execution completes. For long-running functions, use console.log inside loops and Logger.log for one-time entry or exit markers.
What is the difference between the Executions panel and View > Logs?: View > Logs shows only the Logger.log output from the single most recent manual run in the current editor session — it has no history. The Executions panel (clock icon in the left sidebar) shows every run across all triggers and manual executions for the past 14 days, with full log output and error traces expandable per row. Always use the Executions panel for anything beyond the immediately preceding run.

// one good script a week