Got this as a response so we're good!

how do I pretend to be Mallory haha, do they have a username and password that y'all can share?

Hi there, checking in on behalf of the Wikibase Reuse team - is the plan to still have the review done by end of this year?

For more helpful details see conversation here: https://phabricator.wikimedia.org/T410635

For more helpful details see conversation here: https://phabricator.wikimedia.org/T410635

You should look at the raw query logs in event.wdqs_external_sparql_query, and filter records with a status code 500 and query_time` > 60 sec. That's still an approximation, since blazegraph does not return a dedicated status code for timeouts.

Ah wow okay, that helps give me more context. Would you have recommendations then, what might be a good enough heuristic to look for queries that time out?

I've been looking at queries over 60s data on our end to understand user behaviour. I noticed a lot of queries go over the strictly 60000 limit but the exact query time hovers around 60000+5/10 max and only some (ca. 1000 queries) go way above.

We have this as part of a KR for 2026 ("- Wir haben ein Annahmen-Diagramm über Benutzer*innen-Gruppen und User Journeys erstellt, das als Leitfaden für Verbesserungen bei den Zugriffsmethoden und der Dokumentation dient und zu zuverlässigen Ressourcen führt.")

@Jakob_WMDE did you make this randomly or because of a conversation we had?

Marking this as invalid for now since we're going to check whether it makes sense to add this as part of GraphQL. Will re-open if it becomes valid again

Marking this as invalid for now since we're going to check whether it makes sense to add this as part of GraphQL. Will re-open if it becomes valid again

This ticket is not valid anymore

@WMDE-leszek is this still valid?

we already covered this under Wikidata analytics

I'm glad the issue was resolved for @Monneyboi, and apologies for getting to it this late. I'll add this in our backlog to see to us getting around to improving the error message

Hi @Pepe_piton apologies for only looking at this now! I assume the problem still persists? We can check it on our end then

Haven't heard anything so considering this done and closing the ticket as part of cleaning up our board

we already covered this under Wikidata analytics

Work on these has been prioritized and being worked on in specific tickets related to them

we already covered this under Wikidata analytics

we already covered this under Wikidata analytics

we already covered this under Wikidata analytics

we already covered this under Wikidata analytics

we already covered this under Wikidata analytics

I'm cleaning up tickets on our board and this ticket hasn't been worked on at all since it's inception. In the meanwhile the REST API has been on v1 and we haven't had any feedback on the documentation since.

We've not had this come up so far, but can we can see if we can reproduce it there but I'll defer the final judgement on what to do in this situation to y'all.

Should/would this be reflected in the http status which is currently by default 200 for everything?

working again, all good!

Suggestions on what to track:

• Total number of requests coming - success v failure
• Total number of error types
• Latency/execution time
• Usage across fields

@Lydia_Pintscher anything to follow up on here?