GLOBAL_MAX_CONCURRENT_REQ
GLOBAL_MAX_CONCURRENT_REQ means the VIES front end — not one member state — is handling as many simultaneous requests as it will take. Rare, brief, and retryable.
Good news: no member state is reporting GLOBAL_MAX_CONCURRENT_REQ right now. See the live board →
What it means
This is the service-wide sibling of MS_MAX_CONCURRENT_REQ. The ceiling being hit belongs to VIES itself rather than to any one national database, so it affects every member state at the same time.
The good news is that it is much rarer than the per-member-state limit, and when it does show up it is usually short-lived. It correlates with EU-wide peaks: the start of the working day in Central Europe, and month-end and quarter-end invoicing runs.
The less good news: because it is service-wide, switching which country you query will not help you. Only waiting will.
Which member states return GLOBAL_MAX_CONCURRENT_REQ most
We have not recorded a single GLOBAL_MAX_CONCURRENT_REQ response yet. We started monitoring on 2026-08-09, and this table only ever fills in from things we actually observed — so it stays empty until we see one rather than guessing.
What to do about it
- Back off across your whole VIES integration, not just the country that failed — there is only one shared ceiling.
- Add jitter and a circuit breaker. When you see several of these in a row, stop sending for a minute instead of degrading further.
- Stop doing month-end and quarter-end mass re-validation. Spread bulk verification across the month instead. This is the single biggest lever you have.
- Queue rather than fail. This condition is nearly always transient, so a background job that retries is a much better design than an error message in front of a user.
Frequently asked questions
What causes GLOBAL_MAX_CONCURRENT_REQ?
Aggregate load on the VIES service across all users and all member states — typically during Central European business hours, and at month-end and quarter-end. Nothing you did specifically.
Will querying a different country avoid GLOBAL_MAX_CONCURRENT_REQ?
No, and it is worth not wasting time trying. The limit is on the VIES service as a whole, so every member state is affected at once. Backing off is the only thing that helps.
Is GLOBAL_MAX_CONCURRENT_REQ an outage?
Not really — it is a saturation condition rather than a failure, and it is usually brief. Treat it as retryable, and never as a negative validation result.
Hit a different error?
MS_UNAVAILABLE— MS_UNAVAILABLE means the national VAT database behind VIES is not answering.MS_MAX_CONCURRENT_REQ— MS_MAX_CONCURRENT_REQ means a member state is already handling as many simultaneous VIES lookups as it will take.TIMEOUT— A VIES timeout means no answer arrived before your deadline.
← Live VIES status for all 28 member states
Get an alert when a VIES endpoint goes down
We store your address, the country code and a timestamp — nothing else. To be straight with you: Alerts start shortly, but they are not sending yet. When they do, we will only email you about VIES availability. No newsletter, ever.
Building EU invoicing?
We also make Attestwire, an EN 16931 validation API. Post an invoice as JSON and get back the rule it breaks and how to fix it. Free tier, 100 docs/month, no card needed.
api.attestwire.com/docs · check.attestwire.com — our free French e-invoicing readiness checker.