Fix a failed execution by pasting the log into Co-Pilot

It’s 8:40am. The failure email says TypeError: Cannot read properties of undefined (reading 'getRange') in nightlySync. You have a call at 9. You don’t need a rewrite. You need the smallest change that makes last night’s run succeed, and a safe way to re-run it.

This guide is the incident version of working with Co-Pilot: one failed execution, one handler, one patch. For briefing Co-Pilot when you’re building something new, see Brief NitroGAS Co-Pilot so you get working Apps Script. We won’t repeat that here.

TL;DR

• Executions → filter to Failed → open the run → copy the error, stack, and your log lines
• Paste into NitroGAS Co-Pilot with a tight brief: bound to which sheet, which handler, what changed, what not to touch
• Ask for a minimal patch to one function, not a refactor
• Rehearse on a copy (or dry run), then re-run the real thing and check the output
• Write down what broke in a one-line note next to the fix

Step 1: get the evidence from Executions

In the Apps Script editor, open Executions (the list icon in the left bar):

1. Filter Status: Failed and find the run by time and function name
2. Click it to expand the log: the error message, the line number, and any console.log output
3. Copy all of it: error + stack + your own log lines above the failure

Your log lines are the most useful part. “Read 212 rows from Orders” followed by the crash tells Co-Pilot (and you) far more than the error alone. If you don’t log much yet, a Log sheet you’ll actually read later is a good next project.

Also grab:

• The function that failed (the whole thing, plus any helper named in the stack)
• The header row of the sheet it touches
• What changed recently: a renamed tab, a new column, a teammate’s edit

Step 2: write a tight incident brief

Vague: “fix this error.” You’ll get confident code that changes things you didn’t ask about.

Tight:

Context: container-bound script on the "Ops Tracker" spreadsheet. Failing handler: nightlySync (time-driven, runs 2am as me). Error + log from Executions: [paste error, stack, log lines] Function source: [paste nightlySync and getOrdersSheet_] Headers on "Orders": Date | Email | Plan | Price | Source What changed: someone renamed the tab "Orders" to "Orders 2026" yesterday. Ask: the smallest patch to nightlySync / getOrdersSheet_ so this run succeeds. Constraints: - Don't add new services or OAuth scopes - Don't change the trigger or function names - Keep the existing log lines - Fail with a clear message if the tab is missing instead of a TypeError Return: the changed function(s) only, plus one sentence on the root cause.

The constraints are what keep the fix small. “Don’t widen scopes” matters most: a patch that quietly adds UrlFetchApp or Drive access means a new consent screen and a new risk you didn’t sign up for.

Step 3: review the patch like a diff

A good answer for the example above looks like this:

function getOrdersSheet_() { var name = PropertiesService.getScriptProperties().getProperty('ordersTab') || 'Orders'; var sheet = SpreadsheetApp.getActive().getSheetByName(name); if (!sheet) { // Clear message instead of "reading 'getRange' of undefined" three lines later throw new Error('Orders tab "' + name + '" not found. Renamed? Update Script Property ordersTab.'); } return sheet; }

Before you accept anything, check:

• Only the functions you asked about changed
• No new UrlFetchApp, DriveApp, GmailApp, or advanced services unless the job already used them
• No hard-coded ids, emails, or tokens slipped in
• The root-cause sentence matches what you know actually changed
• Existing logging and error handling are still there

If the patch is bigger than you expected, say so: “Too broad. Only change getOrdersSheet_.” Co-Pilot is a collaborator, not an autopilot, and pushing back is part of the process.

Step 4: rehearse, then re-run

1. Paste the patch; save; fix any red squiggles 2. Rehearse: run on a copy of the spreadsheet, or with your dry-run flag on 3. Run the real handler once from the editor (same account as the trigger) 4. Check the output: row counts, the status cell, the Log sheet 5. Confirm tomorrow's scheduled run succeeds in Executions

If the job isn’t safe to run twice (emails, payments, row appends), rehearse first. That’s exactly what a dry-run switch or a throwaway copy is for.

Step 5: leave a breadcrumb

Add one line above the fix:

// 2026-11-05: tab renamed "Orders" → "Orders 2026" broke nightlySync. Tab name now in Script Property ordersTab.

Future you, at 8:40am on some other day, will be grateful.

What not to paste

• API keys, tokens, or Script Property values (redact them: sk_live_…REDACTED)
• Customer data from the log. Trim to a couple of example rows or mask emails
• The entire project. One handler plus its helpers is the right size

Failure modes worth naming

• The error isn’t where it fails: the stack points at line 40, but the bad value came from line 12. Paste the whole function and your log lines.
• Quota / timeout failures: “Exceeded maximum execution time” needs batching or checkpoints, not a one-line patch. Say so in the brief.
• Authorization errors: “You do not have permission” after an edit usually means the trigger owner changed or a scope was added. Check before patching code.
• Flaky upstream API: if the log shows a 5xx from someone else’s API, the fix is retry/backoff, not new logic.

Soft product note

NitroGAS is free in the editor, snippets included. Co-Pilot is the optional part: grab a pass for the week you’re firefighting, paste the incident brief, and get a minimal patch back. You still review it, rehearse it, and press Run.

Closing checklist

• Error, stack, and log lines copied from the failed execution
• Brief names the sheet, the handler, what changed, and the constraints
• Patch touches only the named function(s); no new scopes
• Rehearsed on a copy / dry run, then re-run for real
• One-line breadcrumb comment above the fix

Happy Coding!