URL unreachable (returning 500 errors) but Uptime Kuma monitor says status is "up" and message is "200 - OK"

[shilongjaycui]

⚠️ Please verify that your question has not already been reported

• I have searched the existing issues and found no similar reports.

🛡️ Security Policy

• I have read and agree to Uptime Kuma's Security Policy.

📝 Describe your problem

Hi Uptime Kuma, I'd like to ask for help regarding the following issue I've had for the past two weeks with the tool.

Context:

We host most of our external, client-facing services as well as internal services on Google Cloud's Compute Engine virtual machine (VM) instances. For those services that have a static external IP, we

1. Create a DNS record for the IP in Cloudflare
2. Set up a reverse proxy for the DNS record's corresponding hostname using NGINX
3. Protect the hostname's corresponding URL behind Cloudflare Zero Trust
4. Make sure the service is up and running by adding a Uptime Kuma monitor for the service, with the following configuration:
   • Monitor Type: HTTP(s)
   • URL: https://<server-hostname-specified-in-nginx-configuration>/
   • Heartbeat Interval (Check every 60 seconds): 60
   • Retries: 2
   • Heartbeat Retry Interval (Retry every 60 seconds): 60
   • Request Timeout (Timeout after 48 seconds): 48
   • Resend Notification if Down X times consecutively (Resend disabled): 0
   • Max. Redirects: 10
   • Accepted Status Codes: 200-299
   • Headers:

     {
         "CF-Access-Client-Id": "<cloudflare-access-client-id>",
         "CF-Access-Client-Secret": "<cloudflare-access-client-secret>"
     }

We've had this same set up all year, and it worked great until earlier this month.

Issue:

The issue was first detected on Wednesday, Oct 15 at 8:52pm MT. We found out that one of our services was offline, which surprised us because the service's Uptime Kuma monitor didn't send us an alert; instead, the monitor kept saying status is "up" and message is "200 - OK". When we brought the service back online, the monitor also didn't send us a notification.

It's been almost 10 days since the issue was first detected. At this point, we are aware that at least half of the monitors aren't working (although we've confirmed that some of the monitors are working, sending us alerts when the correspond services went down). For those services, I've had to manually click on their links every two hours to ensure that they're online, which defeats the purpose of Uptime Kuma.

Our attempts to resolve the issue so far:

1. Restarted Uptime Kuma's Docker container
2. Restarted the Google Cloud Compute Engine VM instance where Uptime Kuma's Docker container is hosted
3. Migrated Uptime Kuma from v1 to v2

Unfortunately, none of those attempts resolved the issue. And we continue to have some Uptime Kuma monitors working and some not working.

📝 Error Message(s) or Log

N/A

🐻 Uptime-Kuma Version

2.0.2

💻 Operating System and Arch

Debian GNU/Linux 12 (bookworm) x86_64

🌐 Browser

Google Chrome 141.0.7390.108 (Official Build) (arm64)

🖥️ Deployment Environment

• Runtime Environment:
  • Docker: Version 28.3.2 (Build 578ccf6)
  • Docker Compose: Version v2.38.2
• Database: N/A
• Database Storage:
  • Filesystem:
    • Linux: ext4
  • Storage Medium: SSD
• Uptime Kuma Setup:
  • Number of monitors: 22

[louislam]

I guess it is related to Cloudflare. For example:

• Cached page on Cloudflare?
• Since you have auth headers. Uptime Kuma can not pass the login page of Cloudflare, and its response code is 200?

Some debugging directions:

• Check other urls like this (it should returns 404):
  https://uptime.kuma.pet/not_found.txt

• You can check the response content by using this debugging env var (need to restart Uptime Kuma):
  UPTIME_KUMA_LOG_RESPONSE_BODY_MONITOR_ID=<your monitor id>

• Also, you can go into Uptime Kuma's terminal, and use curl to check the http request:
  https://github.com/louislam/uptime-kuma/wiki/Troubleshooting

[shilongjaycui]

Here're the results after I went through each of the debugging directions you've provided:

• The https://uptime.kuma.pet/not_found.txt did indeed return 404:
  
• I just ran the following command from Uptime Kuma's terminal, and I got a 200 from it:

  curl -s -o /dev/null -w "%{http_code}" https://github.com/louislam/uptime-kuma/wiki/Troubleshooting

• I restarted Uptime Kuma after adding the following environment variable:

  UPTIME_KUMA_LOG_RESPONSE_BODY_MONITOR_ID=51

  where I knew Monitor 51 is one of the monitors that are not working. However, I didn't see the response content in the Uptime Kuma Docker container's logs:

  2025-10-25T10:05:00-06:00 [MONITOR] INFO: Get Monitor: 51 User ID: 1
  2025-10-25T10:05:28-06:00 [SOCKET] INFO: New polling connection, IP = 172.18.0.1
  2025-10-25T10:05:28-06:00 [AUTH] INFO: Login by token. IP=172.18.0.1
  2025-10-25T10:05:28-06:00 [AUTH] INFO: Username from JWT: Unissued7
  2025-10-25T10:05:29-06:00 [AUTH] INFO: Successfully logged in user Unissued7. IP=172.18.0.1
  2025-10-25T10:05:37-06:00 [MONITOR] INFO: Get Monitor: 51 User ID: 1
  2025-10-25T10:05:53-06:00 [SOCKET] INFO: New polling connection, IP = 172.18.0.1
  2025-10-25T10:05:54-06:00 [AUTH] INFO: Login by token. IP=172.18.0.1
  2025-10-25T10:05:54-06:00 [AUTH] INFO: Username from JWT: Unissued7
  2025-10-25T10:05:55-06:00 [AUTH] INFO: Successfully logged in user Unissued7. IP=172.18.0.1
  2025-10-25T10:06:01-06:00 [MANAGE] INFO: Pause Monitor: 51 User ID: 1
  2025-10-25T10:06:07-06:00 [MANAGE] INFO: Resume Monitor: 51 User ID: 1

  The logs above that have 51 in them are from me manually clicking on the monitor's Pause, Resume, and Edit buttons, not from the new environment variable. Two follow-up questions regarding this debugging direction:
  • Did I set up the environment variable correctly? Here's my setup:

         .
         ├── .env
         ├── data
         │   ├── docker-tls
         │   ├── kuma.db
         │   ├── screenshots
         │   └── upload
         ├── docker-compose.dev.yaml
         ├── docker-compose.prod.yaml
         ├── nginx
         │   └── uptime_internal.nginx

    where my .env file looks like this:

    COMPOSE_FILE="docker-compose.prod.yaml"
    UPTIME_KUMA_LOG_RESPONSE_BODY_MONITOR_ID=51

    and my docker-compose.prod.yaml file looks like this:

    services:
      uptime-kuma:
        image: louislam/uptime-kuma:2
        container_name: uptime_kuma
        environment:
          UPTIME_KUMA_LOG_RESPONSE_BODY_MONITOR_ID: ${UPTIME_KUMA_LOG_RESPONSE_BODY_MONITOR_ID}
        volumes:
          - type: bind
            source: /opt/uptime/data
            target: /app/data
        ports:
          - 3001:3001
        restart: unless-stopped
    
    volumes:
      data:

    And I'm running the Uptime Kuma Docker container using the following command:

    su -c "docker compose up --wait" -s /bin/sh docker

  • Am I trying to check the response content in the right spot? Here's the command I'm using to check it:

    docker logs -f uptime_kuma

    While the command above was running (allowing me to view Uptime Kuma Docker container's logs real-time), I opened a separate terminal to bring down the service being monitored by Monitor 51. But the same issue persists: The monitor didn't send an alert, still gave the 200 - OK message, and no logs showed up in the first terminal. But when I tried to access that service from my Chrome browser, I got the 502 error code.

[louislam]

Maybe you also need another env var to display the debug message.

NODE_ENV=development

https://github.com/louislam/uptime-kuma/wiki/Environment-Variables#for-development-only

[shilongjaycui]

The NODE_ENV=development environment variable worked. I'm now able to see the debug message in Uptime Kuma's Docker container.

I then proceeded to see what the logs look like when the service monitored by Monitor 51 is online and offline, respectively. The service's URL is https://<service-hostname>/. Here're what the logs looked like when the service was online:

2025-10-25T15:23:34-06:00 [MONITOR] DEBUG: [Flower] Prepare Options for axios
2025-10-25T15:23:34-06:00 [MONITOR] DEBUG: [Flower] Axios Options: {
  "url": "https://<service-hostname>/",
  "method": "get",
  "timeout": 48000,
  "headers": {
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9",
    "CF-Access-Client-Id": "<cloudflare-access-client-id>",
    "CF-Access-Client-Secret": "<cloudflare-access-client-secret>"
  },
  "maxRedirects": 10,
  "signal": {},
  "httpAgent": {
    "_events": {},
    "_eventsCount": 2,
    "defaultPort": 80,
    "protocol": "http:",
    "options": {
      "maxCachedSessions": 0,
      "autoSelectFamily": true,
      "noDelay": true,
      "path": null
    },
    "requests": {},
    "sockets": {},
    "freeSockets": {},
    "keepAliveMsecs": 1000,
    "keepAlive": false,
    "maxSockets": null,
    "maxFreeSockets": 256,
    "scheduling": "lifo",
    "maxTotalSockets": null,
    "totalSocketCount": 0
  },
  "httpsAgent": {
    "_events": {},
    "_eventsCount": 2,
    "defaultPort": 443,
    "protocol": "https:",
    "options": {
      "maxCachedSessions": 0,
      "rejectUnauthorized": true,
      "secureOptions": 4,
      "autoSelectFamily": true,
      "cookies": {
        "jar": {
          "version": "tough-cookie@4.1.4",
          "storeType": "MemoryCookieStore",
          "rejectPublicSuffixes": true,
          "enableLooseMode": false,
          "allowSpecialUseDomain": true,
          "prefixSecurity": "silent",
          "cookies": []
        }
      },
      "noDelay": true,
      "path": null
    },
    "requests": {},
    "sockets": {},
    "freeSockets": {},
    "keepAliveMsecs": 1000,
    "keepAlive": false,
    "maxSockets": null,
    "maxFreeSockets": 256,
    "scheduling": "lifo",
    "maxTotalSockets": null,
    "totalSocketCount": 0,
    "maxCachedSessions": 0,
    "_sessionCache": {
      "map": {},
      "list": []
    }
  }
}
2025-10-25T15:23:34-06:00 [MONITOR] DEBUG: [Flower] Axios Request
2025-10-25T15:23:34-06:00 [CERT] DEBUG: Parsing Certificate Info
2025-10-25T15:23:34-06:00 [CERT] DEBUG: [0] 70:B6:BF:B9:31:C2:90:96:9D:06:8A:79:7E:0E:D4:9C:DB:AC:7E:21
2025-10-25T15:23:34-06:00 [CERT] DEBUG: [1] 10:8F:BF:79:4E:18:EC:53:47:A4:14:E4:37:0C:C4:50:6C:29:7A:B2
2025-10-25T15:23:34-06:00 [CERT] DEBUG: [2] 93:2B:ED:33:9A:A6:92:12:C8:93:75:B7:93:04:B4:75:49:0B:89:A0
2025-10-25T15:23:34-06:00 [CERT] DEBUG: [3] B1:BC:96:8B:D4:F4:9D:62:2A:A8:9A:81:F2:15:01:52:A4:1D:82:9C
2025-10-25T15:23:34-06:00 [CERT] DEBUG: [Last] B1:BC:96:8B:D4:F4:9D:62:2A:A8:9A:81:F2:15:01:52:A4:1D:82:9C
2025-10-25T15:23:34-06:00 [MONITOR] DEBUG: No need to reset sent_history
2025-10-25T15:23:34-06:00 [MONITOR] DEBUG: A4:8F:E4:40:6E:BB:BA:ED:4B:D3:0F:33:44:85:89:3B:B8:66:0B:F6:C2:32:D6:A9:9E:EA:A6:11:CB:F1:0E:1B
2025-10-25T15:23:34-06:00 [MONITOR] DEBUG: A4:8F:E4:40:6E:BB:BA:ED:4B:D3:0F:33:44:85:89:3B:B8:66:0B:F6:C2:32:D6:A9:9E:EA:A6:11:CB:F1:0E:1B
2025-10-25T15:23:35-06:00 [MONITOR] DEBUG: [Flower] Check isImportant
2025-10-25T15:23:35-06:00 [MONITOR] DEBUG: Monitor #51 'Flower': Successful Response: 314 ms | Interval: 60 seconds | Type: http
2025-10-25T15:23:35-06:00 [UPTIME-CALC] DEBUG: Remove old data
2025-10-25T15:23:35-06:00 [MONITOR] DEBUG: [Flower] Send to socket
2025-10-25T15:23:35-06:00 [MONITOR] DEBUG: [Flower] Store
2025-10-25T15:23:35-06:00 [MONITOR] DEBUG: No clients in the room, no need to send stats
2025-10-25T15:23:35-06:00 [MONITOR] DEBUG: [Flower] prometheus.update
2025-10-25T15:23:35-06:00 [MONITOR] DEBUG: [Flower] SetTimeout for next check.
2025-10-25T15:23:35-06:00 [MONITOR] DEBUG: [Flower] Next heartbeat in: 59659ms

I then manually turned off the service so that it was offline. Here're what the logs looked like when the service was offline:

2025-10-25T15:30:34-06:00 [MONITOR] DEBUG: [Flower] Prepare Options for axios
2025-10-25T15:30:34-06:00 [MONITOR] DEBUG: [Flower] Axios Options: {
  "url": "https://<service-hostname>/",
  "method": "get",
  "timeout": 48000,
  "headers": {
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9",
    "CF-Access-Client-Id": "<cloudflare-access-client-id>",
    "CF-Access-Client-Secret": "<cloudflare-access-client-secret>"
  },
  "maxRedirects": 10,
  "signal": {},
  "httpAgent": {
    "_events": {},
    "_eventsCount": 2,
    "defaultPort": 80,
    "protocol": "http:",
    "options": {
      "maxCachedSessions": 0,
      "autoSelectFamily": true,
      "noDelay": true,
      "path": null
    },
    "requests": {},
    "sockets": {},
    "freeSockets": {},
    "keepAliveMsecs": 1000,
    "keepAlive": false,
    "maxSockets": null,
    "maxFreeSockets": 256,
    "scheduling": "lifo",
    "maxTotalSockets": null,
    "totalSocketCount": 0
  },
  "httpsAgent": {
    "_events": {},
    "_eventsCount": 2,
    "defaultPort": 443,
    "protocol": "https:",
    "options": {
      "maxCachedSessions": 0,
      "rejectUnauthorized": true,
      "secureOptions": 4,
      "autoSelectFamily": true,
      "cookies": {
        "jar": {
          "version": "tough-cookie@4.1.4",
          "storeType": "MemoryCookieStore",
          "rejectPublicSuffixes": true,
          "enableLooseMode": false,
          "allowSpecialUseDomain": true,
          "prefixSecurity": "silent",
          "cookies": []
        }
      },
      "noDelay": true,
      "path": null
    },
    "requests": {},
    "sockets": {},
    "freeSockets": {},
    "keepAliveMsecs": 1000,
    "keepAlive": false,
    "maxSockets": null,
    "maxFreeSockets": 256,
    "scheduling": "lifo",
    "maxTotalSockets": null,
    "totalSocketCount": 0,
    "maxCachedSessions": 0,
    "_sessionCache": {
      "map": {},
      "list": []
    }
  }
}
2025-10-25T15:30:34-06:00 [MONITOR] DEBUG: [Flower] Axios Request
2025-10-25T15:30:34-06:00 [CERT] DEBUG: Parsing Certificate Info
2025-10-25T15:30:34-06:00 [CERT] DEBUG: [0] 70:B6:BF:B9:31:C2:90:96:9D:06:8A:79:7E:0E:D4:9C:DB:AC:7E:21
2025-10-25T15:30:34-06:00 [CERT] DEBUG: [1] 10:8F:BF:79:4E:18:EC:53:47:A4:14:E4:37:0C:C4:50:6C:29:7A:B2
2025-10-25T15:30:34-06:00 [CERT] DEBUG: [2] 93:2B:ED:33:9A:A6:92:12:C8:93:75:B7:93:04:B4:75:49:0B:89:A0
2025-10-25T15:30:34-06:00 [CERT] DEBUG: [3] B1:BC:96:8B:D4:F4:9D:62:2A:A8:9A:81:F2:15:01:52:A4:1D:82:9C
2025-10-25T15:30:34-06:00 [CERT] DEBUG: [Last] B1:BC:96:8B:D4:F4:9D:62:2A:A8:9A:81:F2:15:01:52:A4:1D:82:9C
2025-10-25T15:30:34-06:00 [MONITOR] DEBUG: No need to reset sent_history
2025-10-25T15:30:34-06:00 [MONITOR] DEBUG: A4:8F:E4:40:6E:BB:BA:ED:4B:D3:0F:33:44:85:89:3B:B8:66:0B:F6:C2:32:D6:A9:9E:EA:A6:11:CB:F1:0E:1B
2025-10-25T15:30:34-06:00 [MONITOR] DEBUG: A4:8F:E4:40:6E:BB:BA:ED:4B:D3:0F:33:44:85:89:3B:B8:66:0B:F6:C2:32:D6:A9:9E:EA:A6:11:CB:F1:0E:1B
2025-10-25T15:30:35-06:00 [MONITOR] DEBUG: [Flower] Check isImportant
2025-10-25T15:30:35-06:00 [MONITOR] DEBUG: Monitor #51 'Flower': Successful Response: 221 ms | Interval: 60 seconds | Type: http
2025-10-25T15:30:35-06:00 [UPTIME-CALC] DEBUG: Remove old data
2025-10-25T15:30:35-06:00 [MONITOR] DEBUG: [Flower] Send to socket
2025-10-25T15:30:35-06:00 [MONITOR] DEBUG: [Flower] Store
2025-10-25T15:30:35-06:00 [MONITOR] DEBUG: [Flower] prometheus.update
2025-10-25T15:30:35-06:00 [MONITOR] DEBUG: [Flower] SetTimeout for next check.
2025-10-25T15:30:35-06:00 [MONITOR] DEBUG: [Flower] Next heartbeat in: 59715ms

They look identical to me. This makes me think that Uptime Kuma wasn't aware of the service going offline at all.

Why do think this is happening? You mentioned Cloudflare's cached page earlier. I've not worked with Cloudflare's cached page before, but I'll do some research on it right now.

[shilongjaycui]

I just did the same test on a monitor that works (Monitor 6). Here are the logs from when the service was offline:

2025-10-25T15:56:23-06:00 [MONITOR] DEBUG: [Grafana] Prepare Options for axios
2025-10-25T15:56:23-06:00 [MONITOR] DEBUG: [Grafana] Axios Options: {
  "url": "https://<service-hostname>/",
  "method": "get",
  "timeout": 48000,
  "headers": {
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9",
    "CF-Access-Client-Id": "cloudflare-access-client-id",
    "CF-Access-Client-Secret": "cloudflare-access-client-secret"
  },
  "maxRedirects": 10,
  "signal": {},
  "httpAgent": {
    "_events": {},
    "_eventsCount": 2,
    "defaultPort": 80,
    "protocol": "http:",
    "options": {
      "maxCachedSessions": 0,
      "autoSelectFamily": true,
      "noDelay": true,
      "path": null
    },
    "requests": {},
    "sockets": {},
    "freeSockets": {},
    "keepAliveMsecs": 1000,
    "keepAlive": false,
    "maxSockets": null,
    "maxFreeSockets": 256,
    "scheduling": "lifo",
    "maxTotalSockets": null,
    "totalSocketCount": 0
  },
  "httpsAgent": {
    "_events": {},
    "_eventsCount": 2,
    "defaultPort": 443,
    "protocol": "https:",
    "options": {
      "maxCachedSessions": 0,
      "rejectUnauthorized": true,
      "secureOptions": 4,
      "autoSelectFamily": true,
      "cookies": {
        "jar": {
          "version": "tough-cookie@4.1.4",
          "storeType": "MemoryCookieStore",
          "rejectPublicSuffixes": true,
          "enableLooseMode": false,
          "allowSpecialUseDomain": true,
          "prefixSecurity": "silent",
          "cookies": []
        }
      },
      "noDelay": true,
      "path": null
    },
    "requests": {},
    "sockets": {},
    "freeSockets": {},
    "keepAliveMsecs": 1000,
    "keepAlive": false,
    "maxSockets": null,
    "maxFreeSockets": 256,
    "scheduling": "lifo",
    "maxTotalSockets": null,
    "totalSocketCount": 0,
    "maxCachedSessions": 0,
    "_sessionCache": {
      "map": {},
      "list": []
    }
  }
}
2025-10-25T15:56:23-06:00 [MONITOR] DEBUG: [Grafana] Axios Request
2025-10-25T15:56:23-06:00 [CERT] DEBUG: Parsing Certificate Info
2025-10-25T15:56:23-06:00 [CERT] DEBUG: [0] 70:B6:BF:B9:31:C2:90:96:9D:06:8A:79:7E:0E:D4:9C:DB:AC:7E:21
2025-10-25T15:56:23-06:00 [CERT] DEBUG: [1] 10:8F:BF:79:4E:18:EC:53:47:A4:14:E4:37:0C:C4:50:6C:29:7A:B2
2025-10-25T15:56:23-06:00 [CERT] DEBUG: [2] 93:2B:ED:33:9A:A6:92:12:C8:93:75:B7:93:04:B4:75:49:0B:89:A0
2025-10-25T15:56:23-06:00 [CERT] DEBUG: [3] B1:BC:96:8B:D4:F4:9D:62:2A:A8:9A:81:F2:15:01:52:A4:1D:82:9C
2025-10-25T15:56:23-06:00 [CERT] DEBUG: [Last] B1:BC:96:8B:D4:F4:9D:62:2A:A8:9A:81:F2:15:01:52:A4:1D:82:9C
2025-10-25T15:56:23-06:00 [MONITOR] DEBUG: No need to reset sent_history
2025-10-25T15:56:23-06:00 [MONITOR] DEBUG: A4:8F:E4:40:6E:BB:BA:ED:4B:D3:0F:33:44:85:89:3B:B8:66:0B:F6:C2:32:D6:A9:9E:EA:A6:11:CB:F1:0E:1B
2025-10-25T15:56:23-06:00 [MONITOR] DEBUG: A4:8F:E4:40:6E:BB:BA:ED:4B:D3:0F:33:44:85:89:3B:B8:66:0B:F6:C2:32:D6:A9:9E:EA:A6:11:CB:F1:0E:1B
2025-10-25T15:56:23-06:00 [MONITOR] DEBUG: [Grafana] Check isImportant
2025-10-25T15:56:23-06:00 [MONITOR] WARN: Monitor #6 'Grafana': Pending: Request failed with status code 502 | Max retries: 2 | Retry: 1 | Retry Interval: 60 seconds | Type: http
2025-10-25T15:56:23-06:00 [UPTIME-CALC] DEBUG: Remove old data
2025-10-25T15:56:23-06:00 [MONITOR] DEBUG: [Grafana] Send to socket
2025-10-25T15:56:23-06:00 [MONITOR] DEBUG: [Grafana] Store
2025-10-25T15:56:23-06:00 [MONITOR] DEBUG: [Grafana] prometheus.update
2025-10-25T15:56:23-06:00 [MONITOR] DEBUG: [Grafana] SetTimeout for next check.
2025-10-25T15:56:23-06:00 [MONITOR] DEBUG: [Grafana] Next heartbeat in: 59822ms

As you can see, Uptime Kuma was able to detect that the service was offline and return the 502 status code, hence the WARN message.

To recap, Monitor 6 works, but Monitor 51 doesn't work. The two monitors have the exact same header: CF-Access-Client-Id and CF-Access-Client-Secret. The only difference is that Monitor 6 was created way before Monitor 51 was created.

[louislam]

To recap, Monitor 6 works, but Monitor 51 doesn't work.

Yes, as you can see the http requests are the same as each others, that's why I guess it is related to Cloudflare.

It looks like the UPTIME_KUMA_LOG_RESPONSE_BODY_MONITOR_ID is not activated yet. If it is working, it will print the actual HTML code after [MONITOR] DEBUG: [Flower] Axios Request.

uptime-kuma/server/model/monitor.js

Lines 581 to 583 in 83c3cfc

	if (process.env.UPTIME_KUMA_LOG_RESPONSE_BODY_MONITOR_ID === this.id) {
	log.info("monitor", res.data);
	}

BTW, don't forget to check if your service actually returns 5XX code in the Chrome's developer console, because some SPA web apps cannot reports a correct code due to some limitations.

Like Uptime Kuma's frontend, it cannot show 404

https://status.kuma.pet/not_found

[shilongjaycui]

I examined the Chrome developer console's Network tab while my service was online, and here's what I saw in the console:

I then took the service offline and then refreshed the webpage, and here's what I saw in the console:

As you can see in the second screenshot, the service actually returns the 502 code in the Chrome developer console.

[shilongjaycui]

It looks like the UPTIME_KUMA_LOG_RESPONSE_BODY_MONITOR_ID is not activated yet. If it is working, it will print the actual HTML code after [MONITOR] DEBUG: [Flower] Axios Request.

I agree that the UPTIME_KUMA_LOG_RESPONSE_BODY_MONITOR_ID is not activated yet, as I don't see HTML code in the Uptime Kuma Docker container's logs. Here's how I'm currently activating the environment variable (which apparently doesn't work):

.
├── .env
├── data
│   ├── docker-tls
│   ├── kuma.db
│   ├── screenshots
│   └── upload
├── docker-compose.prod.yaml

where .env looks like this:

COMPOSE_FILE="docker-compose.prod.yaml"
NODE_ENV=development
UPTIME_KUMA_LOG_RESPONSE_BODY_MONITOR_ID=51

and docker-compose.prod.yaml looks like this:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime_kuma
    environment:
      NODE_ENV: ${NODE_ENV}
      UPTIME_KUMA_LOG_RESPONSE_BODY_MONITOR_ID: ${UPTIME_KUMA_LOG_RESPONSE_BODY_MONITOR_ID}
    volumes:
      - type: bind
        source: /opt/uptime/data
        target: /app/data
    ports:
      - 3001:3001
    restart: unless-stopped

volumes:
  data:

Any idea why the UPTIME_KUMA_LOG_RESPONSE_BODY_MONITOR_ID isn't being activated even though it was being passed into the Docker environment like the NODE_ENV environment variable is? I'll do some more digging on my end too.

[louislam]

My bad, I didn't realize UPTIME_KUMA_LOG_RESPONSE_BODY_MONITOR_ID was broken until now.

The fix (change === to ==)
https://github.com/louislam/uptime-kuma/pull/6271/files

If you don't mind, you can try louislam/uptime-kuma:nightly2, which has fixed the issue. I think it pretty closes to 2.0.2.

[shilongjaycui]

All good. I'm glad we caught the bug! And the fix worked: Now I'm examining the HTML element in the Docker logs for clues of why the alert doesn't respond to the service going online or offline. Will keep you posted on my findings here in this GitHub issue.

[shilongjaycui]

Here's the HTML code (with the super long HTML elements omitted) returned by setting the UPTIME_KUMA_LOG_RESPONSE_BODY_MONITOR_ID=51 environment variable:

<!DOCTYPE html>
<html>
  <head>
    <title>Sign in ・ Cloudflare Access</title>
    <meta charset="utf-8" />
    <meta name="robots" content="noindex" />
    <meta name="viewport" content="initial-scale=1, maximum-scale=1, user-scalable=no, width=device-width" />
    <article id="data"
      data-auto-redirect-to-identity="false"
      data-auto-redirect-url=""
      data-message="">
    </article>
    <style>...</style>

    <!-- URL polyfill for IE11 -->
    <script>...</script>
    <script>...</script>
  </head>

  <body>
    <div class="base_AccessLogo">
        <svg width="165" height="50" fill="none" viewBox="0 0 165 50"><path d="..." fill="#36393A"/></svg>
    </div>
    <div class="Content">

      <div class="AuthBox">
        <div class="AuthBox-body">
          <a class="OrgAvatarLink" href=''>
            <div class="OrgAvatarLink-logo">
              <img height=50 src="" style="display:none;" onload="this.style.display=''"></img>
            </div>
            <div class="OrgAvatarLink-title">
              ...
            </div>
          </a>
          <div class="AuthBox-App">
            <div class="App-name">
              Flower (Prod)
            </div>

          </div>
          <div class="AuthBox-Normal">
              <div class="AuthBox-text">
                Sign in with:
              </div>
              <div class="AuthServiceLogin">
                  <div class="AuthServiceLogin-row AuthServiceLogin-row-is-only">
                    <a class=" Button Button-is-block Button-is-auth js-idp" data-idp="Google Workspace" title="Google Workspace ・ Google Workspace"
                       href="..." accesskey="1" id="idp1">
                      <div class="Button-auth-service-icon"><svg viewBox="0 0 256 262"><path d="..."/></svg></div>
                      <div class="AuthBoxRow--name">Google Workspace ・ Google Workspace</div>
                    </a>
                  </div>
              </div>
              <div class="AuthBox-RequestCode AuthBox-RequestCode__idpsExist">
                <div class="AuthBox-text">Get a login code emailed to you</div>
                <form class="AuthFormLogin" action='' method="post" id="totp-form">
                  <div class="AuthFormLogin-row">
                    <label>Email</label>
                    <input class="StandardInput StandardInput-is-block EmailInput" type="email" required
                           placeholder="example@email.com" spellcheck="false" autocomplete="off" autocapitalize="none"
                           autofocus name="email">
                    <input hidden type="text" name="client_id" value=''>
                    <input hidden type="text" name="connector_id" value=''>
                    <input hidden type="text" name="connector_type" value=''>
                    <input hidden type="text" name="redirect_url" value=''>
                  </div>
                  <div class="AuthFormLogin-row">
                    <button type="submit" form="totp-form" class="Button Button-is-block Button-is-juicy Button-uses-org-theme-accent-color">
                      Send me a code
                    </button>
                  </div>
                </form>
              </div>

          </div>
        </div>
      </div>
    </div>
    <div class="base_TeamsLogo">
        <svg width="275" height="32" fill="none" viewBox="0 0 275 32"><g clip-path="url(#clip0_51_954)" fill="#222"><path d=""/></g><defs><clipPath id="clip0_51_954"><path fill="#fff" d="M0 0h275v32H0z"/></clipPath></defs></svg>
    </div>

    <script>...</script>
  </body>

</html>

As you can see, the HTML code belongs to the Cloudflare login page, not the service itself. I then swapped the value of the UPTIME_KUMA_LOG_RESPONSE_BODY_MONITOR_ID environment variable with the IDs of the other three monitors I know aren't working, and all of their HTML code belong to the same Cloudflare login page.

For a moment, I thought we've found the cause of the issue. However, just out of curiosity, I swapped the value of the environment variable with the ID of a monitor I know is working. To my surprise, that monitor's HTML code also belongs to the Cloudflare login page.

On one hand, I was expecting the HTML code to belong to the actual service being monitored; on the other hand, I was expecting the HTML code from a not-working monitor vs. from a working monitor to be different. Now I'm confused. Am I missing/misunderstanding something?

[louislam]

Wait, I just googled something, and suprisingly, it linked back to this repo's old issue. I think he provided a solution that exactly you want.

#4951 (comment)

[shilongjaycui]

Hey louislam! Thank you for linking the possible solution to our issue above. I haven't had a chance to try it out yet, since I don't have access to Cloudflare at my organization and the team responsible for it is currently busy with a more urgent task. But I haven't forgotten about our conversations, and I'll keep you posted on whether the possible solution works or not.