Gmail Trigger Error

[nidhi-patel]

Describe the problem/error/question

Gmail Trigger Node issue: I’m encountering an issue with my workflow using the Gmail Trigger node in n8n version 2.20.7 and it was same for 2.20.6. My workflow is set to poll for unread emails every minute now have set to 5 min to not overburden with execution count, but it is counting executions even when no unread emails are found which is also logging it as an error in execution tab. This behavior is different from version 2.16, where such cases were not counted as executions. How can I configure my workflow so that it does not count executions when no emails are found? For now I am catching the specific kind of error and setting is to nothing, my only worry is it’s increasing my execution count and in this way I will surpass the monthly limit. I noticed this issue as I updated yesterday from 2.16.# to 2.20.6 as latest stable and today to 2.20.7 as latest stable.

What is the error message (if any)?

No specific error, it just shows: Problem in node ‘Gmail Trigger’ and in other information it shows the search query details as cause

[
{
“trigger”: {
“error”: {
“name”: “IsolateError”,
“cause”: {
“q”: “=from:@domain.com -from:group@domain.com newer_than:1d”,
“readStatus”: “unread”
}
},
“mode”: “trigger”
},
“workflow”: {
“id”: “#####”,
“name”: “Gmail Workflow Name”
}
}
]

Please share your workflow

Please note I have replaced the Id’s and names and email address with dummy data or #### so I don’t accidentally release confidential details.

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)
{
  "nodes": [
    {
      "parameters": {
        "pollTimes": {
          "item": [
            {
              "mode": "everyX",
              "value": 5,
              "unit": "minutes"
            }
          ]
        },
        "maxResults": 1,
        "filters": {
          "q": "==from:@domain.com -from:group@domain.com newer_than:1d",
          "readStatus": "unread"
        }
      },
      "type": "n8n-nodes-base.gmailTrigger",
      "typeVersion": 1.4,
      "position": [
        656,
        1104
      ],
      "id": "#####,
      "name": "Group Gmail Trigger",
      "alwaysOutputData": false,
      "notesInFlow": false,
      "credentials": {
        "gmailOAuth2": {
          "id": "####",
          "name": "Gmail Group Support Gmail2"
        }
      }
    }
  ],
  "connections": {
    "Group Gmail Trigger": {
      "main": [
        []
      ]
    }
  },
  "pinData": {},
  "meta": {
    "templateCredsSetupCompleted": true,
    "instanceId": "#####"
  }
}

Share the output returned by the last node

Error details
Other info
n8n version
2.20.7 (Cloud)
Error cause
{ “q”: “=from:@domain.com -from:group@domain.com newer_than:1d”

Information on your n8n setup

• n8n version: 2.20.7
• Database (default: SQLite):
• n8n EXECUTIONS_PROCESS setting (default: own, main):
• Running n8n via (Docker, npm, n8n cloud, desktop app): n8n cloud
• Operating system:

I look forward to any insights or if this is an error which is required fix by those who maintain the Gmail Trigger Node or to n8n version?

Thank you,

Nidhi Patel

[kjooleng]

@nidhi-patel

My workflow is set to poll for unread emails every minute now have set to 5 min

5x12x24x31 = 44640 executions per month

@nidhi-patel

but it is counting executions even when no unread emails are found

I believe this is the correct behaviour since workflow is triggered

[nidhi-patel]

Thank you, @kjooleng - but earlier it wasn’t the case, and on the other hand, it’s throwing it as an error , which is also an unusual behavior. any insights on that?

Thank you,

NP

[nguyenthieutoan]

Hi @nidhi-patel! Good question about the error part specifically.

On the behavior change from v2.16: you’re right that this did change. In earlier versions, polling triggers that found no results would exit cleanly without logging an execution. From around v2.17+ onwards, every polling cycle is recorded as an execution regardless of whether it found anything. This was a deliberate change for observability, though it does have the side effect you’re seeing on cloud plans with execution limits.

On the error being thrown: the IsolateError you’re seeing is likely not a Gmail API error but rather n8n internally throwing because the node received 0 results and the trigger’s error handling is surfacing that as an error event. A few things to try:

1. In the Gmail Trigger node settings, check if there’s an “On Error” option. Set it to “Continue” if available.
2. Alternatively, switch from the Gmail Trigger node to a Schedule Trigger that fires every 5 minutes, followed by a Gmail node in “Get Many” mode with your filter query. Then add an IF node to check if the result array is empty before continuing. This gives you full control and the schedule trigger itself doesn’t throw on empty results.

The Schedule + Gmail Get Many approach is actually more flexible long term, since you can add retry logic, filter more precisely, and it’s easier to debug.

Hope that helps!

[nidhi-patel]

Thank you @nguyenthieutoan , appreciate explaining. I already have what you suggested in place, but I am not happy to see error when there is “No New Email” with Gmail Trigger Node and funny thing it is saying query is the cause, so the error message is wrong as well as it’s misleading spent much time confirming if the query format is changed by Google.

I think at most it shouldn’t log as an error, as it isn’t. And possibly have another approach may be as an Info or even warning or simply log it, The other problem for me is it’s getting it counted as an execution and not having clean break also forces me indirectly cave into upgrading the plan, or opt to self host, I think that’s a huge take away from this scenario for me. As earlier I was on Gmail Trigger Node v1.2 so I updated to v1.4 but all it did is added max item per poll setting. Also before upgrading the change log doesn’t show much details that I will fall in this issue, didn’t manage to test before upgrading was a huge mistake.

The Setup I have is:

1: Gmail Trigger Node: Settings → On Error : stop workflow, and a node which check if it has legit id then I use the id to get the full message via API to further process it.

-> The next thing I can try is to add a loop, so I can loop through the new email which are not processed and push the execution triggers from 5 min to 30 min to decrease execution, if internally it’s approved.

2: Error workflow to which I had to add a special scenario not to trigger followup notification on subsequent channels to fix the error .

I am not sure but I can’t seem to find a way to revert to an older version.

May be n8n team can evaluate and see if this has a value :

-> To keep execution logs de-cluttered and not log when no emails found as an error as in reality it isn’t an error. As than only it will help with meaningful investigation of real errors, when needed.

-> To have Gmail Trigger node have clean break

-> Not count as an execution when there is no error, as in reality it’s the web-hook checking for new email, the whole flow doesn’t need to get executed.

Anyway, thank you for the details you shared. appreciate it. Please let me know if there a any other approach I should try.

Best,

NP

[kjooleng]

@nidhi-patel

but I can’t seem to find a way to revert to an older version.

Can you do this?

The dropdown should allow you to change versions

[nguyenthieutoan]

You’ve raised some really valid points here, NP, and honestly this kind of detailed breakdown is exactly what the n8n team needs to hear.

You’re completely right that logging a “no new email” scenario as an error is misleading. It’s not an error in any meaningful sense, it’s just a poll cycle that found nothing. The fact that it also counts as an execution and the error message points to “query” as the cause makes it even more confusing and has real cost implications on cloud plans.

A couple of things that might help in the meantime:

On the error counting: If you switch your Gmail Trigger “On Error” from “Stop Workflow” to “Continue” (ignore errors), the polling cycle still happens but it won’t surface as a failed execution in your error workflow. This reduces the noise in error tracking even if it doesn’t fix the execution count itself.

On the version: @kjooleng’s tip about the version dropdown is the right path if you’re on n8n cloud. You can try selecting 2.19.5 or whichever version was stable before this behavior changed.

Most importantly: I’d strongly encourage you to submit this as a feature/bug request on GitHub at Issues · n8n-io/n8n · GitHub . Your write-up here is already very clear and well-structured. The three points you listed:

• Don’t log empty polls as errors
• Clean break behavior for Gmail Trigger
• Don’t count no-result polls as executions

…are genuinely reasonable UX improvements and the team does act on well-documented community feedback. The more people upvote or +1 it, the better the chance it gets prioritized.

Hope this helps move things forward for you!

[nidhi-patel]

Thank you @kjooleng , I don’t have the version you suggesting, please find the snapshot attached..

let me know if there is another way.

Best,

NP

[nidhi-patel]

Thank you @nguyenthieutoan , I will create it as an issue based on your suggestion, hopefully it will help to sort it out. mean while I will see how I can decrease the frequency of Gmail Trigger.

Appreciate your clear guidance.

Best,

NP

[tamy.santos]

Hi @nidhi-patel

I checked the closest GitHub issues I could find, and none of them seem to be open now. The closest ones are related to Gmail Trigger polling, unread email handling, or differences between manual and automatic trigger behavior, but they do not describe this exact case where an empty poll is logged as an error and counted as an execution. The key point I would report is that an empty poll should not be counted or logged as a failed execution, because “no new email” is a valid trigger state, not an operational error.

[nguyenthieutoan]

Great point from @tamy.santos! That framing is spot on, “no new email” is really just a normal idle state, not an error. Reporting it to GitHub is definitely the right move, @nidhi-patel.

In the meantime, lowering the polling frequency as you mentioned should help keep your execution count in check. If you feel the guidance here has helped clarify the workaround and next steps, feel free to mark the most helpful reply as the Solution so others with the same question can find it quickly!