Gitlab node requires re executing after some time of inactivity

Questions
1

Describe the problem/error/question

I’m experiencing an issue with my workflow that interacts with GitLab using a personal access token. Here’s the scenario:

Day N: The workflow runs perfectly, and all GitLab nodes successfully commit without any issues.
Day N+1 (morning): The workflow is triggered, but no commits are made to GitLab. In the execution history, I see there’s an issue with the GitLab node. but when i immediately re execute the node or the whole workflow, everything works fine

What is the error message (if any)?

Couldn’t connect with these settings

The DNS server returned an error, perhaps the server is offline

Please share your workflow

sorry can't share my workflow but it is a workflow triggered after a form submission, I receive via webhook teams a notification to approve continuity of the workflow, and I  have gitlab nodes that connects to a gitlab intern repo with a personal access token.

Share the output returned by the last node

Information on your n8n setup

  • n8n version: Version 2.4.5
  • Database (default: SQLite): Postgre16
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app): cloud run
  • Operating system:
2

hi @inssaf !

Suggested mitigation

  • Enable retry on failure for the GitLab nodes
  • Add a short wait (5–10s) before the GitLab step after approval
  • Review Cloud Run egress / DNS configuration and limits

No workflow changes appear to be required beyond adding retry or delay logic.

2 Likes
3

I recommend restarting your instance, and also as it works when manually triggered try refreshing your credentials and also make sure the things you are trying to commit using that should not fry the API, let me know if this helps!

1 Like
4

thank you so much

1 Like
5

Thank you! I will first try with the retry on failure option and keep you updated.
(It also works when re-executing automatically, not just manually.)

6

A proof i concept i made for myself here using GIthub:

Very basic auto commiter that triggers and creates a file, maybe you can get something out of it

7

@inssaf If this answer helps, please mark it as the solution to support others in the community!
Thanks!

1 Like
8

Hey folks,

Just wanted to add some context on why this happens - it’s a quirk of running n8n on Cloud Run.

Basically: Cloud Run scales to zero when idle. So when your workflow hasn’t run for a while, the container shuts down completely. Next morning when it triggers, Cloud Run spins up a fresh container. The problem is Node.js doesn’t cache DNS by default, and during that cold start the first DNS lookup can fail before everything is fully initialized.

That’s why re-executing immediately works - the container is already warm at that point and DNS resolves fine.

Retry on failure should definitely help for most cases. If you’re still seeing issues after that, the nuclear option is setting min_instances: 1 in Cloud Run, keeps one container always warm. Costs a bit more but completely eliminates the cold start problem.

Let me know how retry works out. :wink:

1 Like
9

Hello, thanks for this great explanation, the retry worked for me !

10

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.