Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Embedded searx-checker #1559

dalf opened this issue Apr 11, 2019 · 1 comment


None yet
2 participants
Copy link

commented Apr 11, 2019

I've updated searx-checker to produce an html output, see
Source code based on work of @kvch :

It shows which engines currently doesn't work (warning : some engine may work / not work from time to time).

The thing that would be nice is to be able test the different searx instances.
Example : the first instance in is
This instance answers quickly with the last version searx and good security configuration.
But this instance doesn't work : whatever the engine is, whatever the query is, it always shows the same error message. It would be nice to show this information on

Using searx-checker doesn't work : most the searx engines disable and severly limit json output.

A solution is to embed searx-checker inside searx.
Every day searx makes a self test of all the configured engines. It can be done easily if each engine contains a list of queries that are supposed to provide answers (with a default one is not configured).
The result would be available on a /status URL : see for an example.

Then can display a sum up of this information :

  • on the current view : number of working engine per instance (perhaps with a detail per category).
  • another view (to create) : number of working instance per engine.

This comment has been minimized.

Copy link

commented May 17, 2019

That's a good idea! I often want to know which engine is not working on my instance.
Meanwhile why not making instead a program written with a browser engine framework like selenium or puppeteer to check the availability of each engine on a searx instance?
I know it would take much longer and consume more ram and processor but that's the only way currently to avoid the json output restriction and other restrictions as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.