Monitor HTTP Endpoints - Uptime & TLS Expiry Tracking

Overview

The OpenTelemetry Collector can probe an HTTP endpoint on a schedule and report the result as metrics. This gives you uptime monitoring for any HTTP or HTTPS URL, without an agent inside the application.

With this guide you can:

Probe your endpoints on a schedule and record whether they respond.
See endpoint health, latency, and response size in a SigNoz dashboard.
Get an alert when an endpoint stops responding.
Track TLS certificate expiry.
Catch a 200 response that carries an error body.

The checks run from the Collector host. Each measurement covers the network path from that host to the endpoint, not the path your users take. Run the Collector outside the network that hosts the endpoint to measure user-facing uptime. Run it inside that network to measure internal reachability.

Most steps are identical. To adapt this guide, update the endpoint and remove the ingestion key header as shown in Cloud to Self-Hosted.

Prerequisites

A server or virtual machine to run the OpenTelemetry Collector. The checks run from this host.
Network access from the Collector host to each endpoint that you want to monitor.

Setup

Step 1: Install the OpenTelemetry Collector

Install the Collector on your server with the Collector installation guide. That guide covers Docker, Kubernetes, VM, and AWS ECS.

Step 2: Add the HTTP Check Receiver

The HTTP Check Receiver sends a request to each target on a schedule. It records the response as metrics.

Add this receiver to your Collector configuration file:

receivers:
  # On Collector v0.150.0 and newer, use "http_check" to avoid a deprecation warning.
  httpcheck:
    targets:
      - endpoint: https://<your-endpoint>
        method: GET
    collection_interval: 60s

Verify these values:

<your-endpoint>: The URL to monitor, for example api.example.com/health.
method: The HTTP method. Use GET for most health checks.
collection_interval: How often to run the check. Use 30s for critical endpoints.

Step 3: Enable the Optional Metrics

The receiver enables three metrics by default: httpcheck.status, httpcheck.duration, and httpcheck.error. Certificate expiry, response size, and the per-phase timings are off until you turn them on. The dashboard in this guide reads all of them, so enable them now.

Add the metrics block to the receiver you created in Step 2:

receivers:
  httpcheck:
    metrics:
      httpcheck.tls.cert_remaining:
        enabled: true
      httpcheck.response.size:
        enabled: true
      httpcheck.dns.lookup.duration:
        enabled: true
      httpcheck.client.connection.duration:
        enabled: true
      httpcheck.tls.handshake.duration:
        enabled: true
      httpcheck.client.request.duration:
        enabled: true
      httpcheck.response.duration:
        enabled: true

What each one gives you:

Metric	What you get
`httpcheck.tls.cert_remaining`	Seconds left on each verified certificate
`httpcheck.response.size`	Response body size, which drops when an error page replaces the real response
The five duration metrics	Which phase is slow: DNS, TCP connect, TLS handshake, request write, response read

The five duration metrics report nanoseconds. httpcheck.duration reports milliseconds. Set the unit on every custom panel and alert accordingly.

Step 4: Add the SigNoz Exporter

If you followed the Collector installation guide, the exporter already exists. Go to Step 5.

Otherwise, add the OTLP exporter:

exporters:
  otlp:
    endpoint: "ingest.<region>.signoz.cloud:443"
    tls:
      insecure: false
    headers:
      "signoz-ingestion-key": "<your-ingestion-key>"

Verify these values:

<region>: Your SigNoz Cloud region.
<your-ingestion-key>: Your SigNoz ingestion key.

Step 5: Add the Processor and the Uptime Pipeline

The receiver sets no resource attributes. Without a resource processor, the metrics arrive with no service name and attach to no service in SigNoz.

Give the checks their own metrics pipeline. In a shared pipeline, resource/uptime also processes your application metrics, and action: upsert overwrites the service.name that those metrics already carry.

processors:
  resource/uptime:
    attributes:
      - key: service.name
        value: <service-name>
        action: upsert
 
service:
  pipelines:
    metrics/uptime:
      receivers: [httpcheck]
      processors: [resource/uptime, batch]
      exporters: [otlp]

Verify these values:

<service-name>: The name to group these checks under in SigNoz, for example uptime-monitor.

Add metrics/uptime next to your existing pipelines. Do not add httpcheck to a pipeline that already carries application metrics, and do not add resource/uptime to one. The batch processor referenced here must already exist under processors.

Step 6: Restart the Collector

Restart the Collector to apply the changes. The command depends on how you deployed it. See the Collector installation guide.

Validate

Wait for one collection_interval, then open Metrics in SigNoz and search for httpcheck.

httpcheck metrics listed in the SigNoz Metrics explorer with their type and unit — *httpcheck metrics in the Metrics explorer, with the type and unit of each metric*

If httpcheck.status and httpcheck.duration appear, the checks work.

httpcheck.error is enabled by default, but the receiver records a data point only when a probe fails before it gets a response. A healthy endpoint produces no httpcheck.error data, so the metric is absent here until something breaks.

Import the Uptime Monitoring Dashboard

Import the dashboard before you set up alerts, because the alert flow starts from a dashboard panel.

Get the JSON and the import steps from the Uptime Monitoring dashboard page. Then set the Service variable at the top of the dashboard to the <service-name> you chose in Step 5.

Set Up Alerts

Step 1: Create an Alert from a Dashboard Panel

Open the Availability by Endpoint panel in the Uptime Monitoring dashboard.
Click the dropdown menu (⋮).
Select Create Alerts.

Creating an alert from the dashboard panel dropdown menu — *Create an alert directly from a dashboard panel*

Step 2: Configure the Availability Alert

Set the alert to fire when an endpoint stops returning 2xx responses:

Alert configuration page showing conditions for HTTP endpoint monitoring — *Alert configuration that fires when an endpoint stops responding*

Metric: httpcheck.status
WHERE: http.status_class = 2xx
Avg By: http.url
Condition: below the threshold at least once during the last 5 mins
Threshold: 1

This alert fires when an endpoint returns no 2xx response even once in 5 minutes. Send it to Slack, PagerDuty, email, or another notification channel.

Step 3: Add a Certificate Expiry Alert

Create a second alert on httpcheck.tls.cert_remaining so no certificate expires without warning:

Metric: httpcheck.tls.cert_remaining
Avg By: http.url
Condition: below the threshold at least once during the last 30 mins
Threshold: 1209600

A threshold of 1209600 seconds gives you 14 days of notice. A negative value means the certificate already expired.

Catch a 200 That Lies

A 200 response does not prove the endpoint works. A service can return HTTP 200 with an error page or a stale payload, and every reachability signal stays green. Response validation asserts on the body, so those cases surface.

Add validations to a target and enable the two validation metrics:

receivers:
  httpcheck:
    metrics:
      httpcheck.validation.passed:
        enabled: true
      httpcheck.validation.failed:
        enabled: true
    targets:
      - endpoint: https://<your-endpoint>
        method: GET
        validations:
          - contains: '"status":"ok"'
          - not_contains: '"status":"error"'
          - min_size: 10

Each assertion reports its outcome with a validation.type attribute, so you can tell which check failed:

Assertion	`validation.type`	Use it to
`contains` / `not_contains`	`contains` / `not_contains`	Require or forbid a string in the body
`json_path` with `equals`	`json_path`	Compare a JSON field, for example `$.status` equals `ok`
`min_size` / `max_size`	`size`	Catch truncated or unexpectedly large bodies
`regex`	`regex`	Match a pattern

Then add the Validation Failures by Endpoint and Check panel of the dashboard to your review. A row whose status code is 2xx is a silent failure.

Enabling the two metrics is not enough on its own. The receiver emits validation metrics only for targets that have validations configured, so without assertions both metrics stay absent.

The receiver also skips every assertion when the response body has zero bytes. An endpoint that returns 200 with an empty body produces neither a pass nor a failure, so min_size cannot catch it. Alert on httpcheck.validation.passed falling to 0 as well as on httpcheck.validation.failed rising.

Monitor Multiple Endpoints

One target accepts a list of URLs under endpoints. Use it when every URL shares the same method and interval:

receivers:
  httpcheck:
    targets:
      - method: GET
        endpoints:
          - https://api.example.com/health
          - https://api.example.com/ready
          - https://internal-service.local:8080/ping
    collection_interval: 60s

Use Different Check Intervals

To check some endpoints more often than others, add a second receiver instance. Use the format httpcheck/<name>:

receivers:
  httpcheck/critical:
    targets:
      - method: GET
        endpoint: https://api.example.com/health
    collection_interval: 30s
 
  httpcheck/standard:
    targets:
      - method: GET
        endpoints:
          - https://blog.example.com
          - https://docs.example.com
    collection_interval: 300s

Then add both instances to the uptime pipeline:

service:
  pipelines:
    metrics/uptime:
      receivers: [httpcheck/critical, httpcheck/standard]
      processors: [resource/uptime, batch]
      exporters: [otlp]

The instance name needs a forward slash, as in httpcheck/critical. The name httpcheckcritical causes a configuration error. Keep resource/uptime on this pipeline, or the checks arrive with no service name.

Probe an Endpoint That Needs Auth or a Body

Each target takes the client options of the Collector HTTP client, so you can send headers. Targets also take a request body for POST, PUT, and PATCH:

receivers:
  httpcheck:
    targets:
      - endpoint: https://<your-endpoint>
        method: GET
        headers:
          Authorization: "Bearer <your-token>"
      - endpoint: https://api.example.com/users
        method: POST
        body: '{"name": "probe"}'
    collection_interval: 60s

The receiver sets Content-Type from the body when you set no header for it. A body that starts with { or [ gets application/json. A body that contains = gets application/x-www-form-urlencoded. Any other body gets text/plain.

A probe that writes data changes state on every collection interval. Point POST, PUT, and PATCH targets at an endpoint that is safe to call repeatedly.

Metrics and Attributes Reference

For the full upstream specification, see the HTTP Check Receiver metric documentation.

Default Metrics (always enabled)

Metric	Description	Unit
`httpcheck.status`	`1` if the check resulted in a status code matching the status class, `0` otherwise	1
`httpcheck.duration`	Total duration of the HTTP check	ms
`httpcheck.error`	Recorded only when a probe fails before it gets a response, for example connection refused, DNS failure, or timeout	{error}

Optional Metrics (must be enabled in config)

Metric	Description	Unit
`httpcheck.dns.lookup.duration`	Time spent performing DNS lookup	ns
`httpcheck.client.connection.duration`	Time spent establishing TCP connection	ns
`httpcheck.tls.handshake.duration`	Time spent performing TLS handshake	ns
`httpcheck.client.request.duration`	Time spent sending the HTTP request	ns
`httpcheck.response.duration`	Time spent receiving the HTTP response	ns
`httpcheck.response.size`	Size of response body, recorded only when the body has at least one byte	By (bytes)
`httpcheck.tls.cert_remaining`	Time until TLS certificate expires, as specified by `NotAfter` field in the x.509 certificate. Negative values mean the certificate has already expired	s (seconds)
`httpcheck.validation.failed`	Number of response validations that failed	{validation}
`httpcheck.validation.passed`	Number of response validations that passed	{validation}

httpcheck.status reports one data point per status class on each check. One check gives five data points, 1xx through 5xx. The class that matched carries the http.status_code attribute and the value 1. The other four report 0. Filter on http.status_class to get an up or down signal.

httpcheck.tls.cert_remaining reports only for a certificate that verifies. If a certificate is expired or untrusted, the client refuses the handshake. The receiver then reports httpcheck.error instead.

httpcheck.response.size and the two validation metrics need a response body. A 200 with an empty body produces none of them.

Key Attributes

Attributes vary by metric. The table below shows all attributes and which metrics they apply to:

Attribute	Description	Applies To
`http.url`	Full HTTP request URL	All metrics
`http.status_code`	HTTP response status code	`httpcheck.status`
`http.method`	HTTP request method	`httpcheck.status`
`http.status_class`	HTTP response status class (`1xx` through `5xx`)	`httpcheck.status`
`error.message`	Error message recorded during check	`httpcheck.error`
`network.transport`	OSI transport layer protocol	`httpcheck.client.connection.duration`
`http.tls.issuer`	Certificate issuer	`httpcheck.tls.cert_remaining`
`http.tls.cn`	Certificate common name (CN)	`httpcheck.tls.cert_remaining`
`http.tls.san`	Certificate Subject Alternative Name	`httpcheck.tls.cert_remaining`
`validation.type`	Type of validation (`contains`, `json_path`, `size`, `regex`)	`httpcheck.validation.failed`, `httpcheck.validation.passed`

Troubleshooting

No `httpcheck` metrics appear in SigNoz

Symptoms: You configured the receiver, but no httpcheck.* metric appears in SigNoz.

Causes and fixes:

Receiver not in the pipeline: Make sure that httpcheck is listed under service.pipelines.metrics/uptime.receivers.
Configuration file not loaded: Make sure that the Collector starts with the correct file. Read the startup logs for errors.
Collector not restarted: Restart the Collector after you change the configuration.

The checks arrive with no service name

Symptoms: httpcheck.* metrics exist, but the dashboard Service variable is empty.

Causes and fixes:

Processor missing from the pipeline: Make sure that resource/uptime is listed under the processors of metrics/uptime. The receiver sets no resource attributes of its own.
Second receiver instance on another pipeline: Every httpcheck/<name> instance needs the same processor. See Use Different Check Intervals.

Application metrics changed service name after this setup

Symptoms: Services that reported before now appear under the uptime service name.

Causes and fixes:

Shared pipeline: resource/uptime uses action: upsert, which overwrites service.name on every metric in its pipeline. Move httpcheck and resource/uptime to their own metrics/uptime pipeline, as shown in Step 5.

Connection refused or timeout errors in Collector logs

Symptoms: The Collector logs show connection refused or context deadline exceeded for an endpoint.

Causes and fixes:

Network access: Make sure that the Collector host can reach the endpoint. Do a test with curl <endpoint> from the same host.
Firewall rules: Make sure that firewalls and security groups permit outbound traffic to the endpoint.
DNS resolution: If you use a hostname, do a test with nslookup <hostname> from the Collector host.

Validation reports neither a pass nor a failure

Symptoms: A target has validations and both validation metrics are enabled, but neither metric reports data for that endpoint.

Causes and fixes:

Empty response body: The receiver skips every assertion when the body has zero bytes, so a 200 with an empty body produces no data point. Alert on httpcheck.validation.passed falling to 0, not only on failures rising.
Assertions on the wrong target: validations is a per-target key. Add it to each target you want to assert on.

SSL/TLS errors for HTTPS endpoints

Symptoms: The Collector logs show a TLS handshake error or a certificate error.

Causes and fixes:

Self-signed certificates: If the endpoint uses a self-signed certificate, skip verification. Do not use this in production.

receivers:
  httpcheck:
    targets:
      - endpoint: https://internal-service.local
        tls:
          insecure_skip_verify: true

Expired certificates: The certificate can be expired. Do a test with openssl s_client -connect <host>:443.

Metrics not reaching SigNoz Cloud

Symptoms: The debug logs show successful checks, but no metric appears in SigNoz.

Causes and fixes:

Incorrect ingestion key: Make sure that the signoz-ingestion-key header is correct. Get your key from SigNoz Cloud settings.
Wrong region: Make sure that <region> matches your SigNoz Cloud region. See available regions.
Exporter name mismatch: The name under exporters must match the name in service.pipelines.metrics/uptime.exporters.

Next Steps

Set up a notification channel for Slack, PagerDuty, or email.
Read the Collector configuration reference to add processing and filtering.
Read the HTTP Check Receiver documentation for the full target and client options.

Get Help

If you need help with the steps in this topic, please reach out to us on SigNoz Community Slack. If you are a SigNoz Cloud user, please use in product chat support located at the bottom right corner of your SigNoz instance or contact us at cloud-support@signoz.io.

Monitor HTTP Endpoints - Uptime & TLS Expiry Tracking

Overview

Prerequisites

Setup

Step 1: Install the OpenTelemetry Collector

Step 2: Add the HTTP Check Receiver

Step 3: Enable the Optional Metrics

Step 4: Add the SigNoz Exporter

Step 5: Add the Processor and the Uptime Pipeline

Step 6: Restart the Collector

Validate

Import the Uptime Monitoring Dashboard

Set Up Alerts

Step 1: Create an Alert from a Dashboard Panel

Step 2: Configure the Availability Alert

Step 3: Add a Certificate Expiry Alert

Catch a 200 That Lies

Monitor Multiple Endpoints

Use Different Check Intervals

Probe an Endpoint That Needs Auth or a Body

Metrics and Attributes Reference

Default Metrics (always enabled)

Optional Metrics (must be enabled in config)

Key Attributes

Troubleshooting

No httpcheck metrics appear in SigNoz

The checks arrive with no service name

Application metrics changed service name after this setup

Connection refused or timeout errors in Collector logs

Validation reports neither a pass nor a failure

SSL/TLS errors for HTTPS endpoints

Metrics not reaching SigNoz Cloud

Next Steps

Get Help

No `httpcheck` metrics appear in SigNoz