Self-hosted service
710leo/urlooker avatar
710leo/urlooker

urlooker watches your URLs and pushes the numbers into Nightingale, Falcon or Prometheus

enterprise-level websites monitoring system

563 stars147 forksGoApache-2.0

At a glance

What is it?
urlooker is a Go service that probes HTTP endpoints, records status code, response time and page keywords, and ships the results to Nightingale, Open-Falcon, StatsD or Prometheus. It suits operations teams that want a lightweight URL check feeding an existing metrics stack, and it is a 2020-era codebase with a default admin password and a MySQL dependency, so it needs hardening before any real deployment.
Who is it for?
Adopt urlooker if you want a self-hosted URL and API monitor that writes into an existing metrics backend such as Nightingale, Open-Falcon, StatsD or Prometheus, and you are comfortable maintaining a Go and MySQL service. Do not adopt it as a modern synthetic monitoring platform, because the code targets Go 1.12, the last tagged release was V1.1.0 in April 2020, and the project is built around a MySQL schema rather than a modern time series store.
Can I use it commercially?
Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 105 days ago.
What is it written in?
Mainly Go, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.

Editorial analysis

Endpoint checks and four ways to ship the results

urlooker is described as an enterprise-level websites monitoring system, and its feature list is short enough to state exactly.

It checks the status code of a monitored URL, records the response time, and looks for a page keyword. It lets you customise the request header and customise the POST body, and it supports the GET, POST and PUT methods.

The output side is the part that makes it usable inside an existing operations stack, and the README lists four targets: Nightingale, Open-Falcon, StatsD and Prometheus. The repository topics match that list with api-monitor, url-monitor, website-monitor, prometheus, statsd, nightingale and open-falcon.

That design choice is what separates urlooker from a simple cron job with curl. The check is the easy half. The value is in the exporter, because a URL check that only prints to a log is not a metric, and a metric that does not land in the same Prometheus or Nightingale dashboard as everything else is one more thing to look at.

The project is written in Go, and the repository carries a Dockerfile, a docker-entrypoint.sh, a control script, configs/, dataobj/, modules/, script/ and sql/ directories, an install.sh, and a vendor/ directory with the dependencies committed.

Installing with Docker and the MySQL volume that matters

The Docker path is the documented one, and it is four commands:

bash
git clone https://github.com/710leo/urlooker.git
cd urlooker
docker build .
docker volume create urlooker-vol
docker run -p 1984:1984 -d --name urlooker --mount source=urlooker-vol,target=/var/lib/mysql --restart=always [CONTAINER ID]

The named volume is the point of the run command. It is mounted at /var/lib/mysql, which is where the Dockerfile declares its volume, so the monitoring data survives the container being replaced. The port mapping publishes 1984, which is the same port the service listens on and the one the README tells you to open in a browser.

The Dockerfile itself shows how the image is assembled, and it is a period piece. It starts from golang:1.14, imports a MySQL signing key with apt-key, adds the MySQL community apt repository for jessie with the 5.7 series, installs mysql-server, copies the source and runs ./control build. The build stage therefore carries a full MySQL server and a Go toolchain into the image, and the environment sets a MySQL root password and a temporary root password variable that the entrypoint script then uses.

That is a heavy image, and it depends on an apt repository for a Debian release that has been out of support for years. The jessie-era MySQL package sources are the most likely thing to break first if you try to rebuild the image today.

Installing from code, and the password you have to edit

The code path installs MySQL and the schema first, then runs the install script and starts the service:

bash
# install dependence
yum install -y mysql-server
wget https://raw.githubusercontent.com/710leo/urlooker/master/sql/schema.sql
mysql -h 127.0.0.1 -u root -p < schema.sql

curl https://raw.githubusercontent.com/710leo/urlooker/master/install.sh|bash
cd $GOPATH/src/github.com/710leo/urlooker

# change [mysql root password]to your mysql root password
sed -i 's/urlooker.pass/[mysql root password]/g' configs/web.yml

./control start all

The sed line is the step that matters and it is easy to miss. The shipped configuration contains the literal string urlooker.pass as the database password, and you have to replace it with your own MySQL root password before the service will connect. The same string appears in the Dockerfile as the MySQL root password environment variable, so the two defaults are consistent and both need changing.

After that you open http://127.0.0.1:1984 in a browser. The service is managed by a control script with a start target, and the repository also ships an install.sh that the curl command pipes into bash, which is worth reviewing before you run it on a machine that matters.

The other credential the README documents is the default login for the web interface, admin with the password password. The FAQ section lists it alongside the wiki links and the FAQ page.

The dependency set dates the project precisely

The go.mod is the clearest evidence of what this codebase is and when it was written, and it is worth reading before you plan to run it.

The module is github.com/710leo/urlooker and it declares go 1.12. The web stack is Beego 1.12.0 as the framework, with negroni 1.0.0 for middleware, gorilla/mux 1.7.3 for routing, gorilla/context, gorilla/securecookie, unrolled/render, and stathat.com/c/consistent for consistent hashing, which is what you use to shard work across instances.

Persistence is MySQL through go-sql-driver/mysql 1.4.1 with go-xorm/xorm 0.7.9 as the ORM. The metric exporters are the prometheus client_golang at 0.9.3 and quipo/statsd. Logging is sirupsen/logrus 1.4.2, and there is an LDAP dependency, mmitton/ldap, which is presumably for authenticating operators against a directory rather than the local account.

Every one of these versions is old, and the prometheus client in particular has moved a long way since 0.9.3. The vendored directory in the repository is what makes the build reproducible, which is also why the Docker build works at all rather than failing to resolve a dependency that no longer exists upstream.

The Go toolchain requirement of 1.12 is the practical constraint. A current Go release will not build a module that declares 1.12 without adjustments, and the Dockerfile pins 1.14, which is itself several major versions behind.

What to expect from a service last released in 2020

The release record is the last thing to check, and it sets expectations.

The listed tags are v0.0.3 from March 2017, v1.0.0 from March 2020 and V1.1.0 from April 2020. The last push to the main branch was on 2026-07-10, so the tree is still being touched, but the published versions are six years old and there is nothing in the way of a current release.

Combined with the dependency set, the practical reading is that this is a working system from a specific period rather than a project with an active release cadence. That is not a disqualifier for a monitoring service you run yourself, because a stable check that fires reliably matters more than a fresh version number, but it does change what you should verify before you trust it.

What to verify is specific. Change the default admin and password credentials, since the FAQ documents them publicly. Replace the hard-coded database password in configs/web.yml. Confirm the image still builds given the jessie-era MySQL repository, or install from code on a host with MySQL already present. And check that the Prometheus exporter still produces metrics your current Prometheus version scrapes, since the client library is several years behind.

The alternative approach, worth naming, is to skip a dedicated URL monitor entirely if you already run Prometheus, and use Blackbox Exporter, which probes HTTP endpoints and exports the results as Prometheus metrics by design. The difference in approach is that a blackbox exporter is scraped like any other exporter and stores nothing itself, while urlooker owns a MySQL database, keeps its own history, does keyword matching on the page body, and pushes to a choice of backends including StatsD and Falcon, which are not Prometheus-shaped.

Editorial conclusion

Adopt urlooker if you want a self-hosted URL and API monitor that writes into an existing metrics backend such as Nightingale, Open-Falcon, StatsD or Prometheus, and you are comfortable maintaining a Go and MySQL service. Do not adopt it as a modern synthetic monitoring platform, because the code targets Go 1.12, the last tagged release was V1.1.0 in April 2020, and the project is built around a MySQL schema rather than a modern time series store. Before you deploy, change the default admin and password credentials, replace the hard-coded database password in configs/web.yml, and note that the last push was on 2026-07-10, so the tree is touched but the published versions are six years old.

Frequently asked questions

What does urlooker monitor and where does it send the results?

It checks the status code, the response time and a page keyword for each monitored URL, supports custom request headers and POST bodies, and handles GET, POST and PUT. The README says the results are sent to Nightingale, Open-Falcon, StatsD or Prometheus.

How do I install urlooker with Docker?

Clone the repository, cd into it, run docker build ., create a named volume with docker volume create urlooker-vol, and then run the container with the volume mounted at /var/lib/mysql and port 1984 published. The named volume is what keeps the MySQL data when the container is replaced.

What must I change before running urlooker from source?

The shipped configuration in configs/web.yml contains the literal database password urlooker.pass, and the README shows a sed command replacing it with your own MySQL root password. The README also documents the default web interface login as admin with the password password, which needs changing before any real deployment.

What Go version does urlooker target?

The go.mod declares go 1.12 and the Dockerfile is based on golang:1.14. The dependency set is from the same period, with Beego 1.12.0, gorilla/mux 1.7.3, prometheus client_golang 0.9.3 and go-xorm/xorm 0.7.9, and a vendor/ directory is committed so the build stays reproducible.

How current is urlooker?

The listed releases are v0.0.3 from 2017, v1.0.0 from March 2020 and V1.1.0 from April 2020, and the last push to the main branch was on 2026-07-10. The repository is licensed under Apache-2.0 and publishes no GitHub releases beyond those tags.

Official sources

  1. 710leo/urlooker on GitHub
  2. Issues
  3. License: Apache-2.0
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/710leo-urlooker.svg)](https://hysenlabs.com/projects/710leo-urlooker)

Was this useful?