sentry-uptime-checker-fips

packaged by Chainguard

Chainguard Container for sentry-uptime-checker-fips

FIPS-enabled Sentry uptime monitoring service, which runs HTTP checks against monitored URLs and reports the results

Chainguard Containers are regularly-updated, secure-by-default container images.

Download this Container Image

For those with access, this container image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/sentry-uptime-checker-fips:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

Compatibility Notes

Chainguard's sentry-uptime-checker-fips image is comparable to the upstream uptime-checker image that self-hosted Sentry runs (ghcr.io/getsentry/uptime-checker), with the following differences:

• Like upstream, it runs /usr/local/bin/uptime-checker under tini as the app user (UID 1000), with RUST_BACKTRACE=1 and no default command. The binary is also available at /usr/bin/uptime-checker.
• Upstream adds the SSL.com TLS-T-ECC-R2 intermediate certificate to its CA store, because some sites served through Cloudflare do not send it. This image uses the system CA bundle only, so a check against a site that relies on that intermediate can fail with a TLS error. To restore upstream's behavior, mount a CA bundle that includes the intermediate and point SSL_CERT_FILE at it.
• Like other Chainguard Containers, it has a minimal design with no shell or package manager, and it has few to zero CVEs.

FIPS Support

The sentry-uptime-checker-fips image ships Chainguard's validated redistribution of the OpenSSL FIPS provider module, and the checker takes its cryptography from the system OpenSSL in FIPS mode. HTTPS checks, Redis connections over TLS (rediss://), and Kafka TLS all use OpenSSL; unlike the upstream build, the Redis client does not use rustls with ring. See the FIPS-enabled images guide for supported configurations and operating requirements.

• HTTPS checks only negotiate FIPS-approved protocol versions and cipher suites. A monitored site that offers nothing else fails its check with a tls_error.
• The checker uses SHA-1 only to derive Redis script identifiers and UUIDv5 values, which are not security uses.

Getting Started

The checker reads check configurations from Redis and also serves an API on port 12345 that runs a single check on demand. The following example starts Valkey, an nginx server to monitor, and the checker, then runs an HTTP check against nginx:

docker network create uptime
docker run -d --name valkey --network uptime cgr.dev/ORGANIZATION/valkey:latest
docker run -d --name target --network uptime cgr.dev/ORGANIZATION/nginx:latest

docker run -d --name uptime-checker --network uptime -p 12345:12345 \
  -e UPTIME_CHECKER_REDIS_HOST=redis://valkey:6379 \
  -e UPTIME_CHECKER_PRODUCER_MODE=vector \
  -e UPTIME_CHECKER_ALLOW_INTERNAL_IPS=true \
  cgr.dev/ORGANIZATION/sentry-uptime-checker-fips:latest run

UPTIME_CHECKER_ALLOW_INTERNAL_IPS=true lets the checker reach the nginx container's private address; leave it unset in production so checks cannot probe your internal network. Run the check:

curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"subscription_id": "d7b2c8f0a1e34b5c9d6e7f8091a2b3c4", "interval_seconds": 60, "timeout_ms": 5000, "url": "http://target:8080/"}' \
  http://localhost:12345/execute_config | jq '.check_result | {status, http_status_code: .request_info.http_status_code}'

{
  "status": "success",
  "http_status_code": 200
}

HTTPS checks go through the system OpenSSL in FIPS mode. A check against a public HTTPS site also reports the certificate's expiry, which shows the TLS handshake completed:

curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"subscription_id": "d7b2c8f0a1e34b5c9d6e7f8091a2b3c4", "interval_seconds": 60, "timeout_ms": 5000, "url": "https://www.chainguard.dev/"}' \
  http://localhost:12345/execute_config | jq '.check_result | {status, cert_expiry: .request_info.certificate_info.not_after_timestamp_s}'

Configuration

In self-hosted Sentry, the checker reads check configurations that Sentry writes to Redis and produces results to Kafka. Run it on the same Docker network as those services. This mirrors the self-hosted configuration:

docker run -d --name uptime-checker --network <sentry-network> \
  -e UPTIME_CHECKER_RESULTS_KAFKA_CLUSTER=kafka:9092 \
  -e UPTIME_CHECKER_REDIS_HOST=redis://redis:6379 \
  -e UPTIME_CHECKER_ALLOW_INTERNAL_IPS=false \
  -e UPTIME_CHECKER_FAILURE_RETRIES=1 \
  cgr.dev/ORGANIZATION/sentry-uptime-checker-fips:latest run

UPTIME_CHECKER_FAILURE_RETRIES sets how many times a failed check is retried before it is reported as failed. To resolve check targets through specific name servers instead of the system resolver, set UPTIME_CHECKER_HTTP_CHECKER_DNS_NAMESERVERS to a comma-separated list.

To use this image in self-hosted Sentry, set UPTIME_CHECKER_IMAGE in your .env file to cgr.dev/ORGANIZATION/sentry-uptime-checker-fips:latest.

Documentation and Resources

• uptime-checker on GitHub
• Self-hosted Sentry documentation
• Uptime Monitoring in Sentry

What are Chainguard Containers?

Chainguard's free tier of Starter container images are built with Wolfi, our minimal Linux undistro.

All other Chainguard Containers are built with Chainguard OS, Chainguard's minimal Linux operating system designed to produce container images that meet the requirements of a more secure software supply chain.

The main features of Chainguard Containers include:

• Minimal design, without unnecessary software bloat
• Daily builds to ensure container images are up-to-date with available security patches
• High quality build-time SBOMs attesting to the provenance of all artifacts within the image
• Verifiable signatures provided by Sigstore
• Reproducible builds with Cosign and apko (read more about reproducibility)

For cases where you need container images with shells and package managers to build or debug, most Chainguard Containers come paired with a development, or -dev, variant.

In all other cases, including Chainguard Containers tagged as :latest or with a specific version number, the container images include only an open-source application and its runtime dependencies. These minimal container images typically do not contain a shell or package manager.

Although the -dev container image variants have similar security features as their more minimal versions, they include additional software that is typically not necessary in production environments. We recommend using multi-stage builds to copy artifacts from the -dev variant into a more minimal production image.

Need additional packages?

To improve security, Chainguard Containers include only essential dependencies. Need more packages? Chainguard customers can use Custom Assembly to add packages, either through the Console, chainctl, or API.

To use Custom Assembly in the Chainguard Console: navigate to the image you'd like to customize in your Organization's list of images, and click on the Customize image button at the top of the page.

Learn More

Refer to our Chainguard Containers documentation on Chainguard Academy. Chainguard also offers VMs and Libraries — contact us for access.

Trademarks

This software listing is packaged by Chainguard. The trademarks set forth in this offering are owned by their respective companies, and use of them does not imply any affiliation, sponsorship, or endorsement by such companies.