An easy to use service discovery tool and health check, based upon endpoints defined in a config file,
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.


An easy to use service discovery and health check tool, based upon endpoints defined in an ssd.ini file:

# Number of seconds between health checks.
poll-seconds = 30
port = 1337

# Billing site endpoints, including failover servers.
billing-test =
billing-prod =
billing-prod =
billing-prod =

# Authentication API endpoints, including failover servers.
auth-uat =
auth-prod =
auth-prod =


  • No service registration, just update the ssd.ini file to make changes.
  • Endpoints have names, so you can go from a generic name like 'billing' to an exact endpoint, thus giving service discovery.
  • Multiple endpoints can have the same name, so your app can choose the one with the best health.
  • Polling system checks the status of the endpoints on a regular frequency of your choice.
  • Simple JSON response gives the location and status of all endpoints by name.


  • Working
  • Services API (/services)
  • Health check
  • Endpoint changes automatically loaded without restart

Note that the port and polling frequency cannot be changed without restarting, unlike endpoints which are dynamically reloaded when the config changes.

How to use it

Populate the ssd.ini file and drop it on a server somewhere alongside the built executable of simple-service-discovery. This is a single file and can be downloaded ready-built for Linux, Windows and MacOS from the builds subfolder.

Start it going.

Optional: Point a DNS entry at the running instance so no knowledge of machines, IP addresses etc are required by clients.

Important note

If your endpoints are not fast-responding, please be aware that the polling frequency is based purely on time elapsed and does not allow for the time taken for the checks to be performed. In other words, ensure your frequency is longer than your anticipated checks duration, otherwise you risk overlapping checks.

It should be remembered that this is a service discovery tool, and the health check is an added bonus. Therefore if your use case is primarily as service discovery you probably don't need a high granularity frequency anyway (something like 300 seconds is probably fine).

GET /services

This returns the endpoint(s) as an array of JSON object:

    "name": "auth-prod",
    "endpoint": "",
    "status": 200
    "name": "auth-prod",
    "endpoint": "",
    "status": 200

All endpoints with the given key name are returned, along with their last known HTTP status code.

Building and running

One-off build and run

cd <project-root>
go build -o builds/linux/ssd && ./builds/linux/ssd # Linux
go build -o builds/macos/ssd && ./builds/macos/ssd # Mac OS
go build -o builds\windows\ssd.exe && .\builds\windows\ssd.exe # Windows

Build all platform executables

These are tiny, and so are committed to the repository in the builds folder.

cd <project-root>
./make/ && ./builds/linux/ssd # Linux
./make/ && ./builds/macos/ssd # Mac OS
./make/make-windows.bat && .\builds\windows\ssd.exe # Windows