Version 2.6.4
Over night both our Prod and Dev servers started getting error 400 when trying to sync with Azure key vault. The enterprise apps they are running as do not have expired secretes.
Is there any debugging I can enabled on n8n to get more than error 400?
Jason
Hi @jbenway There is not much you can do on cloud but on self hosted docker, you can use N8N_LOG_LEVEL=debug also here is a more detailed list:
Hi @jbenway
since azure is the one throwing the 400, it already logged exactly why it rejected n8n’s request. you don’t even need to touch your n8n servers. just go into your azure portal, open that specific key vault, and check the diagnostic logs. the failed request will be sitting right there with the exact reason it got blocked.
There’s a known bug after the external secrets refactor in 2.2.0 that breaks provider connections, check External Secrets GCP Connection not working with n8n >= 2.2.0 · Issue #24057 · n8n-io/n8n · GitHub — might be what’s hitting you. Also when you say the enterprise app secrets aren’t expired, double check the client secret on the app registration itself in Azure AD, that’s a different thing from the key vault secrets and a 400 usually means the auth token request failed.
Hi Jason,
A sudden 400 error across both environments suggests something changed on Azure’s side (like API changes, permission updates, or token validation.
Found the issue. One secret had been disabled. It caused n8n to not sync any secrete. One server maintained the sync’d copy of the secrets the other lost them all and had zero secrete listed.
The fact that one disabled secrete caused n8n to not sync at all feels like a bug?
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.