Is VIES Down? › GLOBAL_MAX_CONCURRENT_REQ
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.
No member state reported GLOBAL_MAX_CONCURRENT_REQ in our latest check, as of 2026-09-24 05:45 UTC. Your own request may still get a different answer. 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
| Member state | Occurrences (7d) | Share |
|---|---|---|
| Greece EL | 2 | 22.22% |
| Finland FI | 2 | 22.22% |
| Czechia CZ | 1 | 11.11% |
| Spain ES | 1 | 11.11% |
| Netherlands NL | 1 | 11.11% |
| Slovenia SI | 1 | 11.11% |
| Slovakia SK | 1 | 11.11% |
9 occurrences of GLOBAL_MAX_CONCURRENT_REQ observed across all member states in the last 7 days, from our own 5-minute checks. Monitoring began 2026-08-09.
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 VIES could not get an answer from the country holding the VAT number.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 VIES endpoints
Get an alert when a VIES endpoint goes down
One email when a endpoint stops answering, one when it recovers, and at most one alert per member state every 6 hours — VIES flaps, and we would rather be useful than constant. You will get a confirmation mail immediately, and every message has a one-click unsubscribe.
We store your address, the country code, a timestamp and a record of this signup. Nothing else, no newsletter, and we do not share it.
Building EU invoicing?
We also make Attestwire, an EN 16931 validation API. Post an invoice as JSON or UBL/CII XML 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.