self-hosted Add Uptime Monitoring

Problem Statement

Uptime Monitoring feature is out and it's on Early Release. We should bring that here if it hits General Availability.

Product discussion: https://github.com/getsentry/sentry/discussions/51110 Announcement: https://sentry.io/changelog/uptime-monitoring-early-adopters-release/ Documentation: https://docs.sentry.io/product/alerts/uptime-monitoring/

Solution Brainstorm

The way we'll tell you how to configure this should be versioned (learned this the hard way from User Feedback feature). Grab the version you're currently on (or if yours is higher than any of these, choose the highest one).

Setup guide for 24.8.0
Setup guide for 25.1.0 -- plus custom CA certificates + allow internal IPs
Setup guide for 25.2.0 -- allow internal IPs is now bundled inside the upstream repository & there is a web UI to see the uptime history
Setup guide for 25.3.0 -- some new configs, see here https://github.com/getsentry/uptime-checker/blob/b238224f70e23267febdd4100f02068cb2ba18bc/src/app/config.rs#L122-L144
Setup guide for 25.4.0

Aug 31 '24 01:08 aldy505

Setup guide for 24.8.0

Date of writing: 2024-08-31

Does this works for versions below 24.8.0? I have no idea.

On your docker-compose.yml, add a few new containers:

  uptime-results:
    <<: *sentry_defaults
    command: run consumer uptime-results --consumer-group uptime-results
    profiles:
      - feature-complete
  uptime-checker:
    <<: *restart_policy
    # IMPORTANT, READ THIS!
    # If you trust me enough (although we probably never met), you can use the Docker image I built to save some time, so you can use this:
    # image: "aldy505/sentry-uptime-checker:8ffa29b89b319e4b8e51154e82569796ea74c3af"
    #
    # But if you don't trust me enough and prefer to build from source yourself, use this instead (I'm using this on my instance).
    # If you're using the `image` section above, obviously you'll need to remove this `build` section (or just comment it out).
    build: ./uptime-checker-git
    command: run --config /config.yml
    volumes:
      - type: bind
        read_only: true
        source: ./uptime-checker/config.yml
        target: /config.yml
    # If you don't fancy a config file and prefer environment variables, use this instead (and remove the `volume` block above):
    # environment:
    #  UPTIME_CHECKER_REDIS_HOST: "redis://redis:6379"
    #  UPTIME_CHECKER_RESULTS_KAFKA_CLUSTER: "kafka:9092"
    #  UPTIME_CHECKER_RESULTS_KAFKA_TOPIC: "uptime-results"
    #  UPTIME_CHECKER_CONFIGS_KAFKA_CLUSTER: "kafka:9092"
    #  UPTIME_CHECKER_CONFIGS_KAFKA_TOPIC: "uptime-configs"
    #  UPTIME_CHECKER_CHECKER_CONCURRENCY: "200"
    #  UPTIME_CHECKER_LOG_LEVEL: "error"
    depends_on:
      kafka:
        <<: *depends_on-healthy
      redis:
        <<: *depends_on-healthy
    profiles:
      - feature-complete

On your sentry/sentry.conf.py, add some new feature flags:

SENTRY_FEATURES.update(
    {
        feature: True
        for feature in (
          # The rest of your features
        )
        # Uptime Monitoring related flags
        + (
            "organizations:uptime-api-create-update",
            "organizations:uptime-automatic-hostname-detection",
            "organizations:uptime-automatic-subscription-creation",
            "organizations:uptime-rule-api",
            "organizations:uptime-create-issues",
            "organizations:uptime-settings",
            "organizations:uptime-visible", # This is for issues platform
            "organizations:uptime-ingest",
            "organizations:uptime-post-process-group",
        )
    }
)

Create a new directory called uptime-checker, create a config.yml file. The resulting path is uptime-checker/config.yml. You don't need to do this if you're using environment variable as config on the docker-compose.yml:

# See https://github.com/getsentry/uptime-checker/blob/8ffa29b89b319e4b8e51154e82569796ea74c3af/src/app/config.rs
# You could technically use environment variable instead of this file, if you prefer, but I think it's better to use this instead.
# If you really want to use environment variables, do something like: UPTIME_CHECKER_SENTRY_DSN UPTIME_CHECKER_REDIS_HOST, you know the rest.

# sentry_dsn: <string, optional>
# sentry_env: <string, optional>
log_level: error # valid values: off, trace, debug, info, warn, error
log_format: auto # valid values: auto, pretty, simplified, json

checker_concurrency: 200

results_kafka_cluster: "kafka:9092"
results_kafka_topic: "uptime-results"
configs_kafka_cluster: "kafka:9092"
configs_kafka_topic: "uptime-configs"

redis_host: "redis://redis:6379"

If on the docker-compose.yml file you're not using the Docker image that I built, add a line on install.sh:

# ...
source install/update-docker-images.sh
source install/build-uptime-checker.sh # Add this (also remove this comment)
source install/build-docker-images.sh
# ...

And create the file install/build-uptime-checker.sh (still if you're not using the Docker image that I built):

echo "${_group}Building uptime-checker ... "

rm -rf uptime-checker-git

git clone --depth 1 https://github.com/getsentry/uptime-checker.git uptime-checker-git

echo "${_endgroup}"

After all that, run the ./install.sh script. Good luck.

Aug 31 '24 01:08 aldy505

@evanpurkhiser @wedamija Hey, someone on Discord (link: https://discord.com/channels/621778831602221064/1320980341061849109) reported that no issues are registered when the server is down, they have set up the alerts for uptime checker. They're building the Docker image from source. Is there anything that's missing from my setup/config above?

Dec 30 '24 10:12 aldy505

Setup Guide for 25.1.0

Date of writing: 2025-01-16

Add some new containers on your docker-compose.yml:

  uptime-checker:
    <<: *restart_policy
    image: "$UPTIME_IMAGE"
    command: run
    environment:
      UPTIME_CHECKER_SENTRY_DSN: "$SENTRY_DSN"
      UPTIME_CHECKER_RESULTS_KAFKA_CLUSTER: kafka:9092
      UPTIME_CHECKER_RESULTS_KAFKA_TOPIC: uptime-results
      UPTIME_CHECKER_CONFIGS_KAFKA_CLUSTER: kafka:9092
      UPTIME_CHECKER_CONFIGS_KAFKA_TOPIC: uptime-configs
      UPTIME_CHECKER_REDIS_HOST: redis://redis:6379
      UPTIME_CHECKER_LOG_LEVEL: debug # Valid options: info, warn, error, debug
    depends_on:
      kafka:
        <<: *depends_on-healthy
      redis:
        <<: *depends_on-healthy
    profiles:
      - feature-complete
  uptime-results:
    <<: *sentry_defaults
    command: run consumer uptime-results --consumer-group uptime-results
    profiles:
      - feature-complete
  snuba-uptime-results-consumer:
    <<: *snuba_defaults
    command: rust-consumer --storage uptime_monitor_checks --consumer-group snuba-uptime-results --auto-offset-reset=latest --max-batch-time-ms 750 --no-strict-offset-reset
    profiles:
      - feature-complete

For snuba-uptime-results-consumer if you have problem with rust-consumer just use regular Python consumer.

On your .env or .env.custom file, just add this:

UPTIME_IMAGE=aldy505/sentry-uptime-checker:latest

To be honest, I'm tired of having the install script that builds the Docker image locally, so I'll just build this regularly every release (or every time I do upgrades).

Then on your sentry/sentry.conf.py add these feature flags:

SENTRY_FEATURES.update(
    {
        feature: True
        for feature in (
            # ... the original feature flags
        )
        # Uptime Monitoring related flags
        + (
            "organizations:uptime-automatic-hostname-detection",
            "organizations:uptime-automatic-subscription-creation",
            "organizations:uptime-create-issues",
            "organizations:uptime-settings",
            "organizations:uptime-visible", # For issues platform, I don't know if this is still required
            "organizations:uptime-ingest",
            "organizations:uptime-post-process-group",
            "organizations:insights-uptime", # Enables `Uptime` section on the web UI, but this don't really works, you can't access it.
        )
    }
)

After all that, re run ./install.sh script.

Allow internal IPs

By default, uptime-checker container deny request to internal IPs. Since we're on self-hosted, we can bypass that. But that requires something to be changed. Simply set your Docker image on .env file to:

UPTIME_IMAGE=aldy505/sentry-uptime-checker:allow-internal-ips

Custom CA Certificates

Again, on self-hosted, we're bound to weird setups. Store your CA certificates on the certificates directory (the directory already exists, with gitignore in it). Modify your docker-compose.yml (notice on image, build and volumes section are different than the usual).

  uptime-checker:
    <<: *restart_policy
    image: uptime-checker-local
    build:
      context: .
      dockerfile: ./uptime-checker/Dockerfile
      args:
        - UPTIME_IMAGE
    command: run
    environment:
      UPTIME_CHECKER_SENTRY_DSN: "$SENTRY_DSN"
      UPTIME_CHECKER_RESULTS_KAFKA_CLUSTER: kafka:9092
      UPTIME_CHECKER_RESULTS_KAFKA_TOPIC: uptime-results
      UPTIME_CHECKER_CONFIGS_KAFKA_CLUSTER: kafka:9092
      UPTIME_CHECKER_CONFIGS_KAFKA_TOPIC: uptime-configs
      UPTIME_CHECKER_REDIS_HOST: redis://redis:6379
      UPTIME_CHECKER_LOG_LEVEL: debug
    volumes:
      - ./certificates:/ca-certificates:ro # This!
    depends_on:
      kafka:
        <<: *depends_on-healthy
      redis:
        <<: *depends_on-healthy
    profiles:
      - feature-complete

Create uptime-checker/Dockerfile file (a Dockerfile file within uptime-checker directory):

ARG UPTIME_IMAGE
FROM ${UPTIME_IMAGE}

USER root
COPY ./certificates /ca-certificates
RUN cat /ca-certificates/* >> /etc/ssl/certs/ca-certificates.crt
USER app

No need to run install.sh, just do: sudo docker compose --env-file .env --env-file .env.custom up -d --build --wait uptime-checker

Jan 16 '25 00:01 aldy505

Setup Guide for 25.2.0

Date of writing: 2025-02-27

If you're using custom CA certificate or self-signed TLS certificate, read until the end, don't waste your time by executing install.sh multiple times.

Modify your Docker Compose file:

  uptime-checker:
    <<: *restart_policy
    image: "$UPTIME_IMAGE"
    command: run
    environment:
      UPTIME_CHECKER_SENTRY_DSN: "$SENTRY_DSN" # Set this to your internal SENTRY_DSN to monitor this container
      UPTIME_CHECKER_RESULTS_KAFKA_CLUSTER: "kafka:9092"
      UPTIME_CHECKER_CONFIGS_KAFKA_CLUSTER: "kafka:9092"
      UPTIME_CHECKER_REDIS_HOST: "redis://redis:6379"
      UPTIME_CHECKER_LOG_LEVEL: "debug" # Valid options: info, warn, error, debug
      # If you are using statsd to monitor metrics and stuff, you can uncomment this:
      # UPTIME_CHECKER_STATSD_ADDR: "127.0.0.1:8125"
      # If you want to enable HTTP connection reuse to save up connection time, you can set this to true, otherwise, just comment it out:
      # UPTIME_CHECKER_DISABLE_CONNECTION_REUSE: true
    depends_on:
      kafka:
        <<: *depends_on-healthy
      redis:
        <<: *depends_on-healthy
    profiles:
      - feature-complete
  uptime-results:
    <<: *sentry_defaults
    command: run consumer uptime-results --consumer-group uptime-results
    profiles:
      - feature-complete
  snuba-uptime-results-consumer:
    <<: *snuba_defaults
    command: rust-consumer --storage uptime_monitor_checks --consumer-group snuba-uptime-results --auto-offset-reset=latest --max-batch-time-ms 750 --no-strict-offset-reset
    profiles:
      - feature-complete

On your .env file (or .env.custom), add this:

UPTIME_IMAGE=aldy505/sentry-uptime-checker:9574780ba9ca367e87e656ab6468e4923020bae9

On your sentry/sentry.conf.py, update your feature flags:

SENTRY_FEATURES.update(
    {
        feature: True
        for feature in (
            # ... the original feature flags
        )
        # Uptime Monitoring related flags
        + (
            "organizations:uptime",
            "organizations:slack-threads-refactor-uptime", # Enable new slack threads logic for uptime issues
            "organizations:insights-uptime", # Enable access to insights uptime view
            "organizations:uptime-automatic-hostname-detection",
            "organizations:uptime-automatic-subscription-creation",
            "organizations:uptime-create-issues", # Enable creating issues via the issue platform
            "organizations:uptime-settings", # Enables uptime related settings for projects and orgs
            # Below these are for issues platform
            "organizations:uptime-domain-failure-visible",
            "organizations:uptime-domain-failure-ingest",
            "organizations:uptime-domain-failure-post-process-group",
        )
    }
)

On your sentry/config.yml, add this line on the very bottom:

uptime.snuba_uptime_results.enabled: true

Then, run ./install.sh script and you're done.

Just trust me on that image, you can also build it yourself but why even bother. I provide both linux/amd64 and linux/arm64 image. Here's how I build it for future reference (which probably just for me):

sudo docker buildx build --platform linux/arm64,linux/amd64 --tag "aldy505/sentry-uptime-checker:$(git log -1 --format=%H | xargs)" . && \
sudo docker image tag "aldy505/sentry-uptime-checker:$(git log -1 --format=%H | xargs)" "aldy505/sentry-uptime-checker:latest" && \
sudo docker image push "aldy505/sentry-uptime-checker" --all-tags

Custom CA Certificates

If your URL contains self-signed TLS certificate, you should do some modifications after applying all that above. Store your CA certificates on the certificates directory (the directory already exists, with gitignore in it).

On your docker-compose.yml file, modify uptime-checker like so:

  uptime-checker:
    <<: *restart_policy
    image: uptime-checker-local
    build:
      context: .
      dockerfile: ./uptime-checker/Dockerfile
      args:
        - UPTIME_IMAGE
    command: run
    environment:
      UPTIME_CHECKER_SENTRY_DSN: "$SENTRY_DSN" # Set this to your internal SENTRY_DSN to monitor this container
      UPTIME_CHECKER_RESULTS_KAFKA_CLUSTER: "kafka:9092"
      UPTIME_CHECKER_CONFIGS_KAFKA_CLUSTER: "kafka:9092"
      UPTIME_CHECKER_REDIS_HOST: "redis://redis:6379"
      UPTIME_CHECKER_LOG_LEVEL: "debug" # Valid options: info, warn, error, debug
      # If you are using statsd to monitor metrics and stuff, you can uncomment this:
      # UPTIME_CHECKER_STATSD_ADDR: "127.0.0.1:8125"
      # If you want to enable HTTP connection reuse to save up connection time, you can set this to true, otherwise, just comment it out:
      # UPTIME_CHECKER_DISABLE_CONNECTION_REUSE: true
    volumes:
      - ./certificates:/ca-certificates:ro # This!
    depends_on:
      kafka:
        <<: *depends_on-healthy
      redis:
        <<: *depends_on-healthy
    profiles:
      - feature-complete

Create a directory uptime-checker, create a file Dockerfile inside it. On your uptime-checker/Dockerfile, put this:

ARG UPTIME_IMAGE
FROM ${UPTIME_IMAGE}

USER root
COPY ./certificates /ca-certificates
RUN cat /ca-certificates/* >> /etc/ssl/certs/ca-certificates.crt
USER app

Jan 24 '25 04:01 aldy505

Setup Guide for 25.3.0

Date of writing: 2025-03-18

If you're using custom CA certificate or self-signed TLS certificate, read until the end, don't waste your time by executing install.sh multiple times.

Modify your Docker Compose file:

  uptime-checker:
    <<: *restart_policy
    image: "$UPTIME_IMAGE"
    command: run
    environment:
      UPTIME_CHECKER_SENTRY_DSN: "$SENTRY_DSN" # Set this to your internal SENTRY_DSN to monitor this container
      UPTIME_CHECKER_RESULTS_KAFKA_CLUSTER: "kafka:9092"
      UPTIME_CHECKER_CONFIGS_KAFKA_CLUSTER: "kafka:9092"
      UPTIME_CHECKER_REDIS_HOST: "redis://redis:6379"
      UPTIME_CHECKER_LOG_LEVEL: "debug" # Valid options: info, warn, error, debug
      # Allow uptime checks against internal IP addresses
      UPTIME_CHECKER_ALLOW_INTERNAL_IPS: true
      # If you are using statsd to monitor metrics and stuff, you can uncomment this:
      #UPTIME_CHECKER_STATSD_ADDR: "127.0.0.1:8125"
      # If you want to enable HTTP connection reuse to save up connection time, you can set this to true, otherwise, just comment it out:
      #UPTIME_CHECKER_DISABLE_CONNECTION_REUSE: true
      # Sets the maximum time in seconds to keep idle sockets alive in the http checker.
      #UPTIME_CHECKER_POOL_IDLE_TIMEOUT_SECS: 300
      # The number of times to retry failed checks before reporting them as failed
      #UPTIME_CHECKER_FAILURE_RETRIES: 5
      # DNS name servers to use when making checks in the http checker
      #UPTIME_CHECKER_HTTP_CHECKER_DNS_NAMESERVERS: "8.8.8.8,8.8.4.4"
    depends_on:
      kafka:
        <<: *depends_on-healthy
      redis:
        <<: *depends_on-healthy
    profiles:
      - feature-complete
  uptime-results:
    <<: *sentry_defaults
    command: run consumer uptime-results --consumer-group uptime-results
    profiles:
      - feature-complete
  snuba-uptime-results-consumer:
    <<: *snuba_defaults
    command: rust-consumer --storage uptime_monitor_checks --consumer-group snuba-uptime-results --auto-offset-reset=latest --max-batch-time-ms 750 --no-strict-offset-reset
    profiles:
      - feature-complete

On your .env file (or .env.custom), add this:

UPTIME_IMAGE=aldy505/sentry-uptime-checker:b238224f70e23267febdd4100f02068cb2ba18bc

On your sentry/sentry.conf.py, update your feature flags:

SENTRY_FEATURES.update(
    {
        feature: True
        for feature in (
            # ... the original feature flags
        )
        # Uptime Monitoring related flags
        + (
            "organizations:uptime",
            "organizations:insights-uptime", # Enable access to insights uptime view
            "organizations:uptime-automatic-hostname-detection",
            "organizations:uptime-automatic-subscription-creation",
            "organizations:uptime-create-issues", # Enable creating issues via the issue platform
            "organizations:uptime-settings", # Enables uptime related settings for projects and orgs
            # Below these are for issues platform
            "organizations:uptime-domain-failure-visible",
            "organizations:uptime-domain-failure-ingest",
            "organizations:uptime-domain-failure-post-process-group",
        )
    }
)

On your sentry/config.yml, add this line on the very bottom:

uptime.snuba_uptime_results.enabled: true

Then, run ./install.sh script and you're done.

Just trust me on that image, you can also build it yourself but why even bother. I provide both linux/amd64 and linux/arm64 image. Here's how I build it for future reference (which probably just for me):

sudo docker buildx build --platform linux/arm64,linux/amd64 --tag "aldy505/sentry-uptime-checker:$(git log -1 --format=%H | xargs)" . && \
sudo docker image tag "aldy505/sentry-uptime-checker:$(git log -1 --format=%H | xargs)" "aldy505/sentry-uptime-checker:latest" && \
sudo docker image push "aldy505/sentry-uptime-checker" --all-tags

Custom CA Certificates

If your URL contains self-signed TLS certificate, you should do some modifications after applying all that above. Store your CA certificates on the certificates directory (the directory already exists, with gitignore in it).

On your docker-compose.yml file, modify uptime-checker like so:

  uptime-checker:
    <<: *restart_policy
    image: uptime-checker-local
    build:
      context: .
      dockerfile: ./uptime-checker/Dockerfile
      args:
        - UPTIME_IMAGE
    command: run
    environment:
      UPTIME_CHECKER_SENTRY_DSN: "$SENTRY_DSN" # Set this to your internal SENTRY_DSN to monitor this container
      UPTIME_CHECKER_RESULTS_KAFKA_CLUSTER: "kafka:9092"
      UPTIME_CHECKER_CONFIGS_KAFKA_CLUSTER: "kafka:9092"
      UPTIME_CHECKER_REDIS_HOST: "redis://redis:6379"
      UPTIME_CHECKER_LOG_LEVEL: "debug" # Valid options: info, warn, error, debug
      # Allow uptime checks against internal IP addresses
      UPTIME_CHECKER_ALLOW_INTERNAL_IPS: true
      # If you are using statsd to monitor metrics and stuff, you can uncomment this:
      #UPTIME_CHECKER_STATSD_ADDR: "127.0.0.1:8125"
      # If you want to enable HTTP connection reuse to save up connection time, you can set this to true, otherwise, just comment it out:
      #UPTIME_CHECKER_DISABLE_CONNECTION_REUSE: true
      # Sets the maximum time in seconds to keep idle sockets alive in the http checker.
      #UPTIME_CHECKER_POOL_IDLE_TIMEOUT_SECS: 300
      # The number of times to retry failed checks before reporting them as failed
      #UPTIME_CHECKER_FAILURE_RETRIES: 5
      # DNS name servers to use when making checks in the http checker
      #UPTIME_CHECKER_HTTP_CHECKER_DNS_NAMESERVERS: "8.8.8.8,8.8.4.4"
    volumes:
      - ./certificates:/ca-certificates:ro # This!
    depends_on:
      kafka:
        <<: *depends_on-healthy
      redis:
        <<: *depends_on-healthy
    profiles:
      - feature-complete

Create a directory uptime-checker, create a file Dockerfile inside it. On your uptime-checker/Dockerfile, put this:

ARG UPTIME_IMAGE
FROM ${UPTIME_IMAGE}

USER root
COPY ./certificates /ca-certificates
RUN cat /ca-certificates/* >> /etc/ssl/certs/ca-certificates.crt
USER app

Mar 18 '25 02:03 aldy505

Setup Guide for 25.4.0

Date of writing: 2025-04-17

[!NOTE] Changes from previous version (25.3.0):

~~I do have lots of uptime monitor, having it to use the same redis with relay and sentry containers really caused issues. It kinda make it lags for some unknown reasons. Therefore, on this version, I'd prefer to have a separate Redis instance.~~ Caused more troubles than it intend to be. Don't add another Redis instance.

The log level: debug is causing storage issues, therefore you should try to set it as warn instead. See https://github.com/getsentry/self-hosted/issues/3648

If you're using custom CA certificate or self-signed TLS certificate, read until the end, don't waste your time by executing install.sh multiple times.

Modify your Docker Compose file:

  uptime-checker:
    <<: *restart_policy
    image: "$UPTIME_IMAGE"
    command: run
    environment:
      UPTIME_CHECKER_SENTRY_DSN: "$SENTRY_DSN" # Set this to your internal SENTRY_DSN to monitor this container
      UPTIME_CHECKER_RESULTS_KAFKA_CLUSTER: "kafka:9092"
      UPTIME_CHECKER_CONFIGS_KAFKA_CLUSTER: "kafka:9092"
      UPTIME_CHECKER_REDIS_HOST: "redis://redis:6379"
      # BEWARE! This will spam lots of stuff and cause storage problems. You might want to change this to "warn" instead.
      UPTIME_CHECKER_LOG_LEVEL: "debug" # Valid options: info, warn, error, debug
      # Allow uptime checks against internal IP addresses
      UPTIME_CHECKER_ALLOW_INTERNAL_IPS: true
      # If you are using statsd to monitor metrics and stuff, you can uncomment this:
      #UPTIME_CHECKER_STATSD_ADDR: "127.0.0.1:8125"
      # If you want to enable HTTP connection reuse to save up connection time, you can set this to true, otherwise, just comment it out:
      #UPTIME_CHECKER_DISABLE_CONNECTION_REUSE: true
      # Sets the maximum time in seconds to keep idle sockets alive in the http checker.
      #UPTIME_CHECKER_POOL_IDLE_TIMEOUT_SECS: 300
      # The number of times to retry failed checks before reporting them as failed
      #UPTIME_CHECKER_FAILURE_RETRIES: 5
      # DNS name servers to use when making checks in the http checker
      #UPTIME_CHECKER_HTTP_CHECKER_DNS_NAMESERVERS: "8.8.8.8,8.8.4.4"
    depends_on:
      kafka:
        <<: *depends_on-healthy
      redis:
        <<: *depends_on-healthy
    profiles:
      - feature-complete
  uptime-results:
    <<: *sentry_defaults
    command: run consumer uptime-results --consumer-group uptime-results
    profiles:
      - feature-complete
  snuba-uptime-results-consumer:
    <<: *snuba_defaults
    command: rust-consumer --storage uptime_monitor_checks --consumer-group snuba-uptime-results --auto-offset-reset=latest --max-batch-time-ms 750 --no-strict-offset-reset
    profiles:
      - feature-complete

On your .env file (or .env.custom), add this:

UPTIME_IMAGE=aldy505/sentry-uptime-checker:7f7a88d7b5094a6f830e06232a03ee52733ed796

On your sentry/sentry.conf.py, update your feature flags:

SENTRY_FEATURES.update(
    {
        feature: True
        for feature in (
            # ... the original feature flags
        )
        # Uptime Monitoring related flags
        + (
            "organizations:uptime",
            "organizations:insights-uptime", # Enable access to insights uptime view
            "organizations:uptime-automatic-hostname-detection",
            "organizations:uptime-automatic-subscription-creation",
            "organizations:uptime-create-issues", # Enable creating issues via the issue platform
            "organizations:uptime-settings", # Enables uptime related settings for projects and orgs
            # Below these are for issues platform
            "organizations:uptime-domain-failure-visible",
            "organizations:uptime-domain-failure-ingest",
            "organizations:uptime-domain-failure-post-process-group",
        )
    }
)

# Also add this to make sure that it really works
SENTRY_USE_UPTIME = True

On your sentry/config.yml, add this line on the very bottom:

uptime.snuba_uptime_results.enabled: true

Then, run ./install.sh script and you're done.

Just trust me on that image, you can also build it yourself but why even bother. I provide both linux/amd64 and linux/arm64 image. Here's how I build it for future reference (which probably just for me):

sudo docker buildx build --platform linux/arm64,linux/amd64 --tag "aldy505/sentry-uptime-checker:$(git log -1 --format=%H | xargs)" . && \
sudo docker image tag "aldy505/sentry-uptime-checker:$(git log -1 --format=%H | xargs)" "aldy505/sentry-uptime-checker:latest" && \
sudo docker image push "aldy505/sentry-uptime-checker" --all-tags

Custom CA Certificates

If your URL contains self-signed TLS certificate, you should do some modifications after applying all that above. Store your CA certificates on the certificates directory (the directory already exists, with gitignore in it).

On your docker-compose.yml file, modify uptime-checker like so (everything else is the same as the one I defined on the top, just modify these specific keys):

  uptime-checker:
    image: uptime-checker-local
    build:
      context: .
      dockerfile: ./uptime-checker/Dockerfile
      args:
        - UPTIME_IMAGE
    volumes:
      - ./certificates:/ca-certificates:ro # This!

Create a directory uptime-checker, create a file Dockerfile inside it. On your uptime-checker/Dockerfile, put this:

ARG UPTIME_IMAGE
FROM ${UPTIME_IMAGE}

USER root
COPY ./certificates /ca-certificates
RUN cat /ca-certificates/* >> /etc/ssl/certs/ca-certificates.crt
USER app

Apr 17 '25 01:04 aldy505

Hello @aldy505,

I followed your instructions for 25.4.0, but it seems like the feature still doesn't work on my installation for some reason.

It just shows a blank image:

I'm just going to dump some debug information here just in case it helps someone else trying to activate uptime monitors.

EDIT: I figured it out; just don't use "uptime-redis". I might have missed something somewhere, but it looks like uptime-checker needs to use the regular "redis" instance.

Perhaps it's related to Redis being used as a configuration provider?

I deleted the Redis volume in the past

I happened to delete the main Redis storage volume and recreated it after for another unrelated reason.

docker compose down
docker volume rm sentry-redis
docker volume create sentry-redis
docker compose up -d

Another related issue?

Perhaps it's linked to https://github.com/getsentry/uptime-checker/issues/273 ?

I'm going to check this:

To hack this, I disable and enable the uptime monitor from the web UI, and the uptime:configs:{id} keys on redis was repopulated. But this is kind of a burden if you have lots of monitors.

What's inside my uptime:configs:XX?

In the main Redis:

root@sentry:~/self-hosted/self-hosted|25.4.0 ⇒    docker compose exec -it redis /bin/sh
/data # redis-cli
127.0.0.1:6379> KEYS
(error) ERR wrong number of arguments for 'keys' command
127.0.0.1:6379> KEYS uptime:
(empty array)
127.0.0.1:6379> KEYS uptime:*
 1) "uptime:configs:91"
 2) "uptime:updates:17"
 3) "uptime:updates:118"
 4) "uptime:updates:89"
 5) "uptime:updates:91"
 6) "uptime:updates:33"
 7) "uptime:configs:33"
 8) "uptime:updates:19"
 9) "uptime:configs:89"
10) "uptime:updates:88"
127.0.0.1:6379>

Looks like there are some configs saved there

In the uptime-redis:

root@sentry:~/self-hosted/self-hosted|25.4.0 ⇒    docker compose exec -it uptime-redis /bin/sh
/data # redis-cli
127.0.0.1:6379> KEYS uptime:*
(empty array)
127.0.0.1:6379>

Now, I'm trying to resume and restart the uptime monitor, to see if something changes...

It looks like it didn't affect uptime-redis, but it created uptime:configs:116 in redis.

It looks like this:

127.0.0.1:6379> HGETALL uptime:configs:116
1) "1dfd77b8ce554c3bb8c4841d97ffeff4"
2) "\x89\xafsubscription_id\xd9 1dfd77b8ce554c3bb8c4841d97ffeff4\xa3url\xbbhttps://asdf12981928192.com\xb0interval_seconds<\xaatimeout_ms\xcd\a\xd0\xaerequest_method\xa5PATCH\xafrequest_headers\x90\xaetrace_sampling\xc2\xaeactive_regions\x91\xa7default\xb4region_schedule_mode\xabround_robin"

I can see that it indeed corresponds to my uptime check.

Despite that, after waiting one minute, nothing happens -- no check is done.

Status of the uptime containers

Overview

Containers are up and running

root@sentry:~/self-hosted/self-hosted|25.4.0 ⇒    docker compose ps | grep uptime
sentry-self-hosted-snuba-uptime-results-consumer-1                  getsentry/snuba:25.4.0                                                   "./docker_entrypoint…"   snuba-uptime-results-consumer                  13 minutes ago   Up 13 minutes             1218-1219/tcp
sentry-self-hosted-uptime-checker-1                                 aldy505/sentry-uptime-checker:7f7a88d7b5094a6f830e06232a03ee52733ed796   "/sbin/tini -- /usr/…"   uptime-checker                                 13 minutes ago   Up 13 minutes
sentry-self-hosted-uptime-redis-1                                   redis:6.2.14-alpine                                                      "docker-entrypoint.s…"   uptime-redis                                   13 minutes ago   Up 13 minutes (healthy)   6379/tcp
sentry-self-hosted-uptime-results-1                                 sentry-self-hosted-local                                                 "/etc/sentry/entrypo…"   uptime-results                                 13 minutes ago   Up 13 minutes             9000/tcp

Snuba results consumer

The snuba consumer is up and happy

root@sentry:~/self-hosted/self-hosted|25.4.0 ⇒  docker compose logs -f snuba-uptime-results-consumer
snuba-uptime-results-consumer-1  | 2025-04-19 10:49:41,903 Initializing Snuba...
snuba-uptime-results-consumer-1  | 2025-04-19 10:49:59,718 Snuba initialization took 17.81540765700629s
snuba-uptime-results-consumer-1  | 2025-04-19 10:50:03,343 Initializing Snuba...
snuba-uptime-results-consumer-1  | 2025-04-19 10:50:24,440 Snuba initialization took 21.09750619099941s
snuba-uptime-results-consumer-1  | {"timestamp":"2025-04-19T10:50:24.456635Z","level":"INFO","fields":{"message":"Storage: uptime_monitor_checks, ClickHouse Table Name: uptime_monitor_checks_v2_local, Message Processor: MessageProcessorConfig { python_class_name: \"UptimeMonitorChecksProcessor\", python_module: \"snuba.datasets.processors.uptime_monitors_processor\" }, ClickHouse host: clickhouse, ClickHouse port: 9000, ClickHouse HTTP port: 8123, ClickHouse database: default"},"target":"rust_snuba::consumer"}
snuba-uptime-results-consumer-1  | {"timestamp":"2025-04-19T10:50:24.456757Z","level":"INFO","fields":{"message":"Starting consumer for \"uptime_monitor_checks\"","storage":"uptime_monitor_checks"},"target":"rust_snuba::consumer"}
snuba-uptime-results-consumer-1  | {"timestamp":"2025-04-19T10:50:27.503152Z","level":"INFO","fields":{"message":"Kafka consumer member id: \"rdkafka-1b252725-d538-49f7-80ca-a5a2bdf4e882\""},"target":"sentry_arroyo::backends::kafka"}
snuba-uptime-results-consumer-1  | {"timestamp":"2025-04-19T10:50:27.505904Z","level":"INFO","fields":{"message":"New partitions assigned: {Partition { topic: Topic(\"snuba-uptime-results\"), index: 0 }: 0}"},"target":"sentry_arroyo::processing"}

uptime-checker

It's happy as well, but there is no log output.

If I set it to "debug", I see a lot of stuff

uptime-checker-1  | 2025-04-19T11:05:45.681578Z  INFO uptime_checker::check_config_provider::redis_config_provider: redis_config_provider.loading_initial_configs partition=48 config_count=0
uptime-checker-1  | 2025-04-19T11:05:45.681666Z  INFO uptime_checker::check_config_provider::redis_config_provider: redis_config_provider.loading_initial_configs partition=95 config_count=0
uptime-checker-1  | 2025-04-19T11:05:45.681752Z  INFO uptime_checker::check_config_provider::redis_config_provider: redis_config_provider.loading_initial_configs partition=66 config_count=0
uptime-checker-1  | 2025-04-19T11:05:45.681835Z  INFO uptime_checker::check_config_provider::redis_config_provider: redis_config_provider.loading_initial_configs partition=112 config_count=0
uptime-checker-1  | 2025-04-19T11:05:45.681937Z  INFO uptime_checker::check_config_provider::redis_config_provider: redis_config_provider.loading_initial_configs partition=61 config_count=0
uptime-checker-1  | 2025-04-19T11:05:45.682021Z  INFO uptime_checker::check_config_provider::redis_config_provider: redis_config_provider.loading_initial_configs partition=100 config_count=0
uptime-checker-1  | 2025-04-19T11:05:45.682112Z  INFO uptime_checker::check_config_provider::redis_config_provider: redis_config_provider.loading_initial_configs partition=110 config_count=0
uptime-checker-1  | 2025-04-19T11:05:45.682197Z  INFO uptime_checker::check_config_provider::redis_config_provider: redis_config_provider.loading_initial_configs partition=59 config_count=0
uptime-checker-1  | 2025-04-19T11:05:45.682281Z  INFO uptime_checker::check_config_provider::redis_config_provider: redis_config_provider.loading_initial_configs partition=1 config_count=0
uptime-checker-1  | 2025-04-19T11:05:45.682392Z  INFO uptime_checker::check_config_provider::redis_config_provider: redis_config_provider.loading_initial_configs partition=39 config_count=0
uptime-checker-1  | 2025-04-19T11:05:45.682476Z  INFO uptime_checker::check_config_provider::redis_config_provider: redis_config_provider.loading_initial_configs partition=42 config_count=0
uptime-checker-1  | 2025-04-19T11:05:45.682574Z  INFO uptime_checker::check_config_provider::redis_config_provider: redis_config_provider.loading_initial_configs partition=87 config_count=0
uptime-checker-1  | 2025-04-19T11:05:45.682661Z  INFO uptime_checker::check_config_provider::redis_config_provider: redis_config_provider.loading_initial_configs partition=103 config_count=0
uptime-checker-1  | 2025-04-19T11:05:45.682745Z  INFO uptime_checker::check_config_provider::redis_config_provider: redis_config_provider.loading_initial_configs partition=80 config_count=0
uptime-checker-1  | 2025-04-19T11:05:45.682829Z  INFO uptime_checker::check_config_provider::redis_config_provider: redis_config_provider.loading_initial_configs partition=90 config_count=0
uptime-checker-1  | 2025-04-19T11:05:45.682926Z  INFO uptime_checker::check_config_provider::redis_config_provider: redis_config_provider.loading_initial_configs partition=49 config_count=0
uptime-checker-1  | 2025-04-19T11:05:45.683010Z  INFO uptime_checker::check_config_provider::redis_config_provider: redis_config_provider.loading_initial_configs partition=65 config_count=0
uptime-checker-1  | 2025-04-19T11:05:45.683093Z  INFO uptime_checker::check_config_provider::redis_config_provider: redis_config_provider.loading_initial_configs partition=108 config_count=0
uptime-checker-1  | 2025-04-19T11:05:45.683178Z  INFO uptime_checker::check_config_provider::redis_config_provider: redis_config_provider.loading_initial_configs partition=20 config_count=0

It looks like it's also checking for my test uptime (partition=116 ?)

uptime-redis

Looks happy.

uptime-redis-1  | 286:C 19 Apr 2025 11:05:00.063 * DB saved on disk
uptime-redis-1  | 286:C 19 Apr 2025 11:05:00.064 * RDB: 0 MB of memory used by copy-on-write
uptime-redis-1  | 1:M 19 Apr 2025 11:05:00.162 * Background saving terminated with success
uptime-redis-1  | 1:M 19 Apr 2025 11:06:19.048 * 10000 changes in 60 seconds. Saving...
uptime-redis-1  | 1:M 19 Apr 2025 11:06:19.049 * Background saving started by pid 311
uptime-redis-1  | 311:C 19 Apr 2025 11:06:19.052 * DB saved on disk
uptime-redis-1  | 311:C 19 Apr 2025 11:06:19.052 * RDB: 0 MB of memory used by copy-on-write
uptime-redis-1  | 1:M 19 Apr 2025 11:06:19.149 * Background saving terminated with success
uptime-redis-1  | 1:M 19 Apr 2025 11:07:38.058 * 10000 changes in 60 seconds. Saving...
uptime-redis-1  | 1:M 19 Apr 2025 11:07:38.058 * Background saving started by pid 337
uptime-redis-1  | 337:C 19 Apr 2025 11:07:38.061 * DB saved on disk
uptime-redis-1  | 337:C 19 Apr 2025 11:07:38.061 * RDB: 0 MB of memory used by copy-on-write
uptime-redis-1  | 1:M 19 Apr 2025 11:07:38.159 * Background saving terminated with success

It contains a lot of "scheduler_process" keys.

root@sentry:~/self-hosted/self-hosted|25.4.0 ⇒    docker compose exec -it uptime-redis redis-cli KEYS "*"
  1) "scheduler_process::33"
  2) "scheduler_process::82"
  3) "scheduler_process::17"
  4) "scheduler_process::116"
.......... snip ...............
123) "scheduler_process::39"
124) "scheduler_process::99"
125) "scheduler_process::78"
126) "scheduler_process::115"
127) "scheduler_process::6"
128) "scheduler_process::59"
root@sentry:~/self-hosted/self-hosted|25.4.0 ⇒  dodocker compose exec -it uptime-redis redis-cli KEYS "*" | grep -v scheduler_process
.... nothing here ......

uptime-results

Seems happy?

root@sentry:~/self-hosted/self-hosted|25.4.0 ⇒  docker compose logs -f uptime-results
uptime-results-1  | Updating certificates in /etc/ssl/certs...
uptime-results-1  | 0 added, 0 removed; done.
uptime-results-1  | Running hooks in /etc/ca-certificates/update.d...
uptime-results-1  | done.
uptime-results-1  | 10:50:18 [INFO] arroyo.processing.processor: New partitions assigned: {Partition(topic=Topic(name='uptime-results'), index=0): 0}
uptime-results-1  | 10:50:18 [INFO] arroyo.processing.processor: Member id: 'rdkafka-8cbd7a6d-74aa-4e36-a46d-74deaf42363f'

What happens if I switch back to "redis" rather than "uptime-redis" ?

I'm thinking maybe, I should use the regular Redis instance to make it work?

It looks like something happened !

I'm not sure if it's because I switched back to the main Redis, because the times don't exactly match. Maybe I just needed to restart uptime-checker, and that's what helped?

I want to move on and work on something else, but if I had to debug further:

I would check if using the main "redis" instance is what helped or not, by switching back to "uptime-redis" and waiting a little
If so, I would try to figure out how to connect the rest of the infrastructure to uptime-redis (the issue might be that the uptime:* keys are not propagated to uptime-redis?)

Thanks !

@aldy505, thanks for working on documenting open-source Sentry !

I don't think I could've got Uptime Monitors to work without your guide.

Apr 19 '25 11:04 clouedoc

@evanpurkhiser @wedamija Hey, someone on Discord (link: https://discord.com/channels/621778831602221064/1320980341061849109) reported that no issues are registered when the server is down, they have set up the alerts for uptime checker. They're building the Docker image from source. Is there anything that's missing from my setup/config above?

Also, I can confirm this. No issue was created when the uptime monitor went down.

I didn't receive an e-mail either.

Apr 19 '25 11:04 clouedoc

@clouedoc Thanks for reporting this! Mine also turned out to be not working... after my own instruction 🤦

Apr 21 '25 13:04 aldy505

@clouedoc Thanks for reporting this! Mine also turned out to be not working... after my own instruction 🤦

I copied redis dump from the old instance(redis) to the new one(uptime-redis). It helped somehow.

Apr 21 '25 22:04 StirlingEngine

A slight bad news: There will be delay on the availability of uptime-checker container.

May 01 '25 02:05 aldy505

Is it possible that you can make it with 25.5.0? Thanks for letting me know.

May 13 '25 11:05 midub

Is it possible that you can make it with 25.5.0? Thanks for letting me know.

@midub sadly, nope

May 15 '25 00:05 aldy505

Hi team,

I’ve been trying to get Uptime Monitoring to create issues in my self-hosted Sentry 25.5.0 installation.

I've carefully followed the official setup guide for version 25.4.0 and even built the container manually from https://github.com/getsentry/uptime-checker using the provided Dockerfile.

Here's what works:

Kafka topics uptime-results are receiving events.

The uptime-results consumer is picking them up:

uptime_active_sent_occurrence uptime_active_resolved missed_window

snuba-uptime-results-consumer (rust-consumer --storage uptime_monitor_checks) receives and processes these messages correctly.

The data is successfully written to ClickHouse (uptime_monitor_checks_v2_local contains valid entries with check_status = 'failure').

Redis and Kafka are healthy. No offset lag.

Uptime check results include proper trace_id, span_id, and even correct project_id.

However:

No issues are being created in Sentry UI (not visible in the linked project).

Environment:

SENTRY_FEATURES.update(...) includes all required uptime feature flags, including organizations:uptime-create-issues.

sentry/config.yml contains: uptime.snuba_uptime_results.enabled: true

Verified the uptime-checker publishes valid messages with status=success/failure.

Additional context:

sentry-uptime-results Kafka topic → Snuba → ClickHouse path is confirmed working.

ClickHouse query:

SELECT check_status, count(*) FROM uptime_monitor_checks_v2_local GROUP BY check_status; returns values like:

success: 5358 failure: 332 missed_window: 218 But no new issues appear in the assigned Sentry project

Any guidance, fix, or workaround would.

Thanks in advance

May 20 '25 14:05 walikoizork

@walikoizork that's what I encountered as well with 25.5. The status checks were working but no new issue was being created. I ended up setting up uptime-kuma. Not integrated with sentry, and much simpler, but at least it gets the job done. I will follow up on this feature though and will enable it once it's ready.

May 21 '25 18:05 radalin

I cannot get the issue working anyway lol. Let's just wait for the official way to set this up (from the uptime team).

May 26 '25 14:05 aldy505

@walikoizork that's what I encountered as well with 25.5. The status checks were working but no new issue was being created. I ended up setting up uptime-kuma. Not integrated with sentry, and much simpler, but at least it gets the job done. I will follow up on this feature though and will enable it once it's ready.

Because the version 25.5 does not include uptime tracking service, it's only available as UI for you to CRUD your items on the UI, there's no uptime service to check it.

Either you need to setup your service using the guide above or wait till sentry team release the official images.

May 28 '25 10:05 codihaus

That's what I tried to mention. The guide is only working partially at the moment for 25.5. It does follow up on the links, and notes if they are up or down but can't create an issue related to that. Hence you don't get a notification if a link is down or not.

May 28 '25 16:05 radalin

Hey folks, we'll prioritize getting uptime to work nicely in self-hosted in the next week or two. Thank you @aldy505 for the detailed instructions and supporting folks here! I'll follow up with an update when we have things ready to go.

EDIT: should be ready to go! if you face any problems, please open a new issue

Jun 17 '25 17:06 gaprl

Setup Guide for 25.6.0 and 25.6.1

Building on ARM64 failed, so there's no point on doing it myself. Use this image from Sentry's Google Artifact Registry instead:

UPTIME_IMAGE=us-central1-docker.pkg.dev/sentryio/uptime-checker/image:625e1fcced49cbbfe1d978f3953793d04dfed100

No change on anytthing else, see the guide for 25.4.0 first.

Jun 21 '25 08:06 aldy505

I am using 25.6.1 and this feature is not working.

x86_64

Jun 21 '25 11:06 barisyild

A official docker image of Sentry's uptime-checker service is now available! (available on Docker Hub and GHCR)

I've opened a PR here to officially add support for uptime features into self hosted https://github.com/getsentry/self-hosted/pull/3787

Will update this post as we get things released and fully functioning :)

Jul 02 '25 21:07 evanpurkhiser

Hello guys, I just checked out 25.6.2 and upgraded, we got uptime service run as well, but I do not see any logs for it. Do we need any other actions to enable uptime monitoring?

Jul 08 '25 13:07 codihaus

Hey @codihaus -- Have you setup an uptime monitor?

Jul 08 '25 14:07 evanpurkhiser

Hey @codihaus -- Have you setup an uptime monitor?

Ya I did.

I checkout tag 25.6.2 for new source + cope the docker-compose.yml from master branch (because tag 25.6.2 docker-compose file does not have uptime service).

Then I ran ./install.sh

But I didnt see it working.

Jul 08 '25 15:07 codihaus

same here. (25.6.2) new install, no upgrade - using install.sh

two monitors setup, none working.

Jul 08 '25 17:07 matthiscock

You may need to update these flags in your sentry.conf.py

https://github.com/getsentry/self-hosted/blob/e2ad04d564385f05e6dfbc62c7ff1c16d5a81297/sentry/sentry.conf.example.py#L332-L348

they were added to the sentry.conf.example.py, but I don't think install.py automatically merges them with your custom conf.

Jul 08 '25 17:07 evanpurkhiser

Hi

Added these into the relevant file (sentry.conf.py)

Stopped docker
Ran install.sh
Started
Waited an hour

Still no data being collected

Jul 09 '25 08:07 matthiscock

Hi @matthiscock ,

Added these into the relevant file (sentry.conf.py) Still no data being collected

Faced the same issue. After some digging, I noticed that option uptime.snuba_uptime_results.enabled is False, despite it being set to True in sentry.conf.py, and its default value also should be True.

I manually set it via CLI using sentry config set uptime.snuba_uptime_results.enabled True and uptime checks immediately started showing in the UI.

Jul 17 '25 14:07 dgorbash

> docker stats --no-stream | sort -k3 -r -h

...
da0349d49a4e sentry-self-hosted-uptime-checker-1 28.85% 35.12MiB / 30.54GiB  0.11%  7.89GB / 16.6GB  61.4kB / 0B  23
...

uptimer checker uses too much cpu, why?

Jul 20 '25 10:07 barisyild

self-hosted self-hosted copied to clipboard

Add Uptime Monitoring

Problem Statement

Solution Brainstorm

Setup guide for 24.8.0

Setup Guide for 25.1.0

Allow internal IPs

Custom CA Certificates

Setup Guide for 25.2.0

Custom CA Certificates

Setup Guide for 25.3.0

Custom CA Certificates

Setup Guide for 25.4.0

Custom CA Certificates

Perhaps it's related to Redis being used as a configuration provider?

I deleted the Redis volume in the past

Another related issue?

What's inside my uptime:configs:XX?

Status of the uptime containers

Overview

Snuba results consumer

uptime-checker

uptime-redis

uptime-results

What happens if I switch back to "redis" rather than "uptime-redis" ?

Thanks !

Setup Guide for 25.6.0 and 25.6.1

self-hosted
self-hosted copied to clipboard