Is it answering?

Every registry, now and over 90 days.

The tool each check called is named beside the source, so you can run the same call yourself and compare. Times are the whole round trip from this server — our own hop included, not just the registry's. Each bar is one day; hover it for how many calls the registry was asked and how many it did not answer.

• data.gov.gr

  search_datasets

  Answering

  755 ms

  90 days ago100% answeredToday
• Diavgeia

  search_decisions

  Answering

  30 ms

  90 days ago100% answeredToday
• Dimos Athinaion

  search_datasets

  Answering

  32 ms

  90 days ago100% answeredToday
• KIMDIS

  search_contracts

  Answering

  26 ms

  90 days ago92.76% answeredToday
• MITOS

  search_procedures

  Answering

  22 ms

  90 days ago100% answeredToday
• Seismoi — Geodynamiko Institouto EAA

  search_earthquakes

  Answering

  179 ms

  90 days ago80.72% answeredToday
• VIES — Elenchos AFM

  list_member_states

  Answering

  23 ms

  90 days ago99.28% answeredToday

What this check actually does.

• It goes through the front door

  Each check is a plain HTTP request to /{country}/api/{source}/{tool}, with the arguments that tool already ships as its example. It measures the whole path a caller uses — this server, the source's adapter, the registry behind it — rather than pinging a registry directly and reporting on something nobody calls.

• It asks a question, not for a record

  Where a source has a search, that is what the check calls. A search exercises the registry's own index, and it is where each source sets its shortest cache lifetime — so a green light is about the last few minutes rather than about whenever some record was first fetched. A source with nothing to search gets its cheapest list instead, never a lookup: a check should not be sending someone else's identifier upstream on every page view.

• An answer may be a cached answer

  Tool results are cached for as long as each source says, so a check can be answered without the registry being touched. That is not a false positive: it is what a caller would get right now, which is the question this page asks. A time in the single milliseconds is the cache; a few hundred is a real round trip.

• Slow and silent

  Over 3 seconds is reported as answering slowly; after 10 the check is abandoned and reported as no answer. A failure that comes back as an error is quoted in the API's own words — every code it can send is listed with what it means.

• Every call counts

  Each call that goes through the server — from an MCP client, from the API, or from the monitor — leaves one row: which registry, which tool, whether it answered, the error's code when it did not, and how long it took. Never the arguments, and never who asked. A day is marked as degraded once more than one call in 100 went unanswered, as an outage past one in 4, and left blank when nothing was asked. A not_found or invalid_input is the caller's own, and counts as answered. Rows are kept for 90 days.

The verdict at the top is one call each — a sample. The bars are the monitor: the same check runs every ten minutes, and every real call is counted beside it, so a bar is never one unlucky moment. To see for yourself, put the same question to a tool in the live console.