Skip to main content
With services and health checks registered in Consul, you can verify which nodes are healthy using three primary interfaces:
InterfaceDescriptionExample Command
DNSResolve name.service.consul via DNS lookupdig @10.0.3.45 -p 8600 front-end-eCommerce.service.consul
APIQuery Consul’s HTTP API for service entriescurl http://10.0.3.45:8500/v1/catalog/service/my-service
UIBrowse the Consul web interfaceOpen http://<consul-server>:8500/ui in your browser
In the sections below, we’ll walk through each method step by step.

​
1. DNS Queries

Using DNS is often the simplest way to discover services in Consul, since most applications already support DNS resolution.

​
How It Works

  1. Your corporate DNS forwards queries for the .consul domain to Consul’s DNS port (8600).
  2. The application looks up database.service.consul as an A record.
  3. Consul responds with the IP addresses of healthy service instances.
  4. The application selects an IP and connects to the service.
The image illustrates a DNS query process involving a Java app microservice and a MySQL database, with a DNS forwarder for consul nodes.
The image is a flowchart illustrating the process of checking service status from a catalog using DNS queries, involving a Java app microservice, DNS, and a MySQL database. It shows the steps of DNS request, forwarding to Consul, returning healthy nodes, responding to the DNS query, and establishing connectivity.
Ensure your firewall allows traffic to port 8600/udp for DNS forwarding.

​
Example: dig against Consul DNS

dig @10.0.3.45 -p 8600 front-end-eCommerce.service.consul
Sample output: 
; <<>> DiG 9.10.6 <<>> @10.0.3.45 -p 8600 front-end-eCommerce.service.consul
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; QUESTION SECTION:
;front-end-eCommerce.service.consul.   IN A

;; ANSWER SECTION:
front-end-eCommerce.service.consul. 0 IN A 10.3.15.67
...
;; SERVER: 10.0.3.45#8600(10.0.3.45)
Consul returned the healthy instance at 10.3.15.67.

​
2. API Requests

When your application can make HTTP requests, the Consul HTTP API lets you retrieve service entries in JSON format.
The image is a diagram showing an API request process involving a Java app microservice and a MySQL database. It illustrates the flow of checking service status from a catalog.

​
Steps

  1. Send a GET request to: 
    http://<consul-server>:8500/v1/catalog/service/<service-name>
  2. Consul returns a JSON array of nodes passing health checks.
  3. Your code parses the array and picks an IP to connect.

​
Example: curl against the Catalog API

curl --request GET http://10.0.3.45:8500/v1/catalog/service/front-end-eCommerce
Sample JSON response: 
[
  {
    "Node": "web-server-01",
    "Address": "10.3.15.67",
    "ServiceName": "front-end-eCommerce",
    "ServiceTags": ["v7.05","production"]
  }
]
Here, only 10.3.15.67 is healthy.

​
3. Consul UI

For human operators, the Consul web UI offers an intuitive overview of services and checks.
  1. Open your browser at http://<consul-server>:8500/ui.
  2. Click Services in the sidebar to list all registered services.
  3. Select a service (e.g., customer-database-ecommerce) to view node details, health status, tags, and metadata.
The image shows a Consul UI displaying the service status from a catalog, highlighting healthy database and front-end services, along with tags and node information.
The Consul UI is unauthenticated by default. Consider enabling ACLs or reverse-proxy authentication in production.
With DNS queries, REST API calls, and the web UI, you have flexible options to check service status in Consul’s catalog and ensure your applications connect to healthy nodes.

Watch Video