searx-instances-uptime: SearXNG monitoring built out of GitHub Actions

Five GitHub Actions workflows do the monitoring

Monitoring for a set of SearXNG and SearX instances runs on GitHub Actions rather than on a monitoring host. The README links five workflow files at the top: `uptime.yml`, `response-time.yml`, `graphs.yml`, `site.yml` and `summary.yml`. The division of labour is visible in the names, since uptime checking, response timing, chart rendering, site publishing and summary regeneration are separate runs. What ties them together is `.upptimerc.yml` at the repository root, and the workflow definitions themselves live under `.github/`. There is no daemon, no database and nothing to keep alive: the checks are whatever the Actions schedules in this repository ask for. The status page is served from GitHub Pages, which is why the live copy at searx-instances.tiekoetter.com and the file sitting in the repository track the same data.

Issues are the incident log and commits are the history

The mapping of GitHub features onto monitoring roles is stated plainly: Issues serve as incident reports, Actions serve as the uptime monitors, and Pages serves the status page. An outage therefore turns into a filed issue, which means the incident trail is readable and searchable through an ordinary issue tracker rather than locked inside a separate service. Each monitored host also gets its own history page, and the History column of the table links to a commit path under `commits/HEAD/history/` for that host, so the record of past checks is versioned in git next to the endpoint definitions. Two things follow from that arrangement. The past is queryable with ordinary git tooling, and the history of a host is stored in the repository rather than only on the rendered page.

Every host gets a history file named after its domain

The `history/` directory at the repository root is where those per host records land, and the file naming is mechanical: the domain with its dots replaced by hyphens. The host `searx.tiekoetter.com` is tracked by `searx-tiekoetter-com.yml`, `paulgo.io` by `paulgo-io.yml`, `anonsearch.win` by `anonsearch-win.yml`, `baresearch.org` by `baresearch-org.yml` and `etsi.me` by `etsi-me.yml`. Those names are not chosen by hand per instance, they follow from the URL, which keeps the mapping from endpoint to history file unambiguous as the list grows. Alongside `history/` the repository carries `api/` for the machine readable side of the published data, `graphs/` for the rendered charts, and `assets/` for the static files the site references.

The README table is regenerated and hand edits are overwritten

The table at the top of the README is output rather than source. A comment above it states that the summary is generated by Upptime and that changes made by hand will be overwritten, and a `prettier-ignore` marker sits above the table so that formatters leave it alone. The heading line above the table carries a generated badge reading Partial outage, while the rows of the table below read Up. The badge is an aggregate and the rows are per endpoint, and the two come from separate workflow runs. The column set is fixed at five: URL, Status, History, Response Time and Uptime. Correcting a number inside that table by editing the file is wasted work, because the next summary run writes it back.

Collapsible cells keep the generated table short

Both numeric columns are wrapped in collapsible cells. Response Time shows a single figure on the summary line with the rest hidden behind it, and Uptime does the same. For the first five hosts in the table the visible response times read 745ms for searx.tiekoetter.com, 598ms for paulgo.io, 327ms for anonsearch.win, 269ms for baresearch.org and 237ms for etsi.me. The visible uptime figures in the same order read 99.73%, 100.00%, 100.00%, 99.84% and 100.00%. What sits behind each cell is a row of links to that host's history page, and that is where the fuller series lives. Folding the extra links away is what allows a long list of instances to stay inside a README rather than pushing every data point into view.

Most of the tracked hosts sit on other operators' domains

The list being watched is not one operator's own deployment. `searx.tiekoetter.com` belongs to the operator behind this repository, which describes itself as the uptime monitor and status page for Tiekötter.com, but `paulgo.io`, `anonsearch.win`, `baresearch.org` and `etsi.me` are separate domains run by other people. That makes the repository closer to a shared directory of publicly reachable SearX and SearXNG endpoints than to an internal ops dashboard. The consequence is that a status change on any row can originate outside the operator's control, whether that is the remote host, the network path to it, or the remote operator's own maintenance. The status vocabulary is small, a green Up marker for a reachable endpoint and an orange partial outage state at the aggregate level.

Forking the repository is the whole deployment story

The arrangement is sold on needing no infrastructure: Upptime is presented as a way to get your own unlimited and free uptime monitor and status page, powered entirely by a GitHub repository. Adopting the same arrangement means starting from a repository of this shape and letting the five workflows do the rest. Nothing at the top level is application code that has to be compiled or installed; the tracked entries are `.gitattributes`, `.github/`, `.upptimerc.yml`, `LICENSE`, `README.md`, `api/`, `assets/`, `graphs/` and `history/`, with Markdown as the primary language. The licence is MIT, the default branch is `master`, and there are no GitHub releases, so there is no versioned artefact to pin. The last push to the repository landed on 30 September 2026.

Editorial conclusion

Use this arrangement when you want a public status page for instances you do not control and can accept that the numbers live in someone else's repository. Check the tracked host list before drawing conclusions from the aggregate badge, and read the per host history file rather than the generated table when you need the detail behind a figure.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository