starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

HTTP status code selection does not allow 0 #3767

New issue

Open

opened 2026-02-28 03:40:20 -05:00 by deekerman · 9 comments

deekerman commented

2026-02-28 03:40:20 -05:00

Owner

Originally created by @julianbraasch on GitHub (Nov 18, 2024).

None

🛡️ Security Policy

I agree to have read this project Security Policy

Description

I'm using the gRPC keyword monitor type which I would like to connect to a ChirpStack instance.
I did confirm that my proto file and method are correct by using Postman for the same request. I noticed that Postman lists "0 OK" as the status code of the response. However, I am unable to add 0 as my desired status code in Uptime Kuma. I am not sure if this is actually the reason why this monitor fails.

👟 Reproduction steps

Add new gRPC monitor

👀 Expected behavior

The monitor returns the response of my proto service

😓 Actual Behavior

The monitor reports a failed connection. Ping statistics are available through. No entries in the event list of the monitor itself.

🐻 Uptime-Kuma Version

1.23.15

💻 Operating System and Arch

macOS 15.1

🌐 Browser

Google Chrome 130.0.6723.119

🖥️ Deployment Environment

Runtime: Docker 4.35.1
Database: Docker volume
Filesystem used to store the database on: APFS on a SSD
number of monitors: 1

📝 Relevant log output

[MONITOR] WARN: Monitor #1 'ChirpStack': Failing: Error in send gRPC 8 Received message larger than max (1752460652 vs 4194304) | Interval: 20 seconds | Type: grpc-keyword | Down Count: 0 | Resend Interval: 0

Originally created by @julianbraasch on GitHub (Nov 18, 2024). ### 📑 I have found these related issues/pull requests None ### 🛡️ Security Policy - [X] I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy) ### Description I'm using the gRPC keyword monitor type which I would like to connect to a ChirpStack instance. I did confirm that my proto file and method are correct by using Postman for the same request. I noticed that Postman lists "0 OK" as the status code of the response. However, I am unable to add 0 as my desired status code in Uptime Kuma. I am not sure if this is actually the reason why this monitor fails. ### 👟 Reproduction steps Add new gRPC monitor ### 👀 Expected behavior The monitor returns the response of my proto service ### 😓 Actual Behavior The monitor reports a failed connection. Ping statistics are available through. No entries in the event list of the monitor itself. ### 🐻 Uptime-Kuma Version 1.23.15 ### 💻 Operating System and Arch macOS 15.1 ### 🌐 Browser Google Chrome 130.0.6723.119 ### 🖥️ Deployment Environment - Runtime: Docker 4.35.1 - Database: Docker volume - Filesystem used to store the database on: APFS on a SSD - number of monitors: 1 ### 📝 Relevant log output ```shell [MONITOR] WARN: Monitor #1 'ChirpStack': Failing: Error in send gRPC 8 Received message larger than max (1752460652 vs 4194304) | Interval: 20 seconds | Type: grpc-keyword | Down Count: 0 | Resend Interval: 0 ```

deekerman added the

bug

A:monitor

type:enhance-existing

labels

2026-02-28 03:40:20 -05:00

deekerman commented

2026-02-28 03:40:24 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Nov 19, 2024):

Received message larger than max

What is the message that the grpc endpoint is responding with?

@CommanderStorm commented on GitHub (Nov 19, 2024): > Received message larger than max What is the message that the grpc endpoint is responding with?

deekerman commented

2026-02-28 03:40:25 -05:00

Author

Owner

@julianbraasch commented on GitHub (Nov 19, 2024):

The result JSON contains a single entry called jwt which contains a JSON Web Token, which admittedly can be quite long

@julianbraasch commented on GitHub (Nov 19, 2024): The result JSON contains a single entry called ```jwt``` which contains a JSON Web Token, which admittedly can be quite long

deekerman commented

2026-02-28 03:40:25 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Nov 19, 2024):

If the message is referring to bits, that would be 219 MB.
If it's bytes that would be 1.7GB

Having a limit against such requests is reasonable.
In postman what is the size of the message in MB?

@CommanderStorm commented on GitHub (Nov 19, 2024): If the message is referring to bits, that would be 219 MB. If it's bytes that would be 1.7GB Having a limit against such requests is reasonable. In postman what is the size of the message in MB?

deekerman commented

2026-02-28 03:40:25 -05:00

Author

Owner

@julianbraasch commented on GitHub (Nov 19, 2024):

I concur with enforcing request limits, but I can assure you they are orders of magnitude lower. The response in Postman was just 250 bytes long.

{
    "jwt": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhdWQiOiJjaGlycHN0YWNrIiwiZXhwIjoxNzMyMDk3MDc3LCJpc3MiOiJjaGlycHN0YWNrIiwic3ViIjoiMDUyNDRmMTItNmRhZi00ZTFmLTgzMTUtYzY2NzgzYTBhYjU2IiwidHlwIjoidXNlciJ9.ZnWatLRzzb3EMo5VVEes-3wzhD3ePJpqt02zqyGnmSs"
}

@julianbraasch commented on GitHub (Nov 19, 2024): I concur with enforcing request limits, but I can assure you they are orders of magnitude lower. The response in Postman was just 250 bytes long. ```json { "jwt": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhdWQiOiJjaGlycHN0YWNrIiwiZXhwIjoxNzMyMDk3MDc3LCJpc3MiOiJjaGlycHN0YWNrIiwic3ViIjoiMDUyNDRmMTItNmRhZi00ZTFmLTgzMTUtYzY2NzgzYTBhYjU2IiwidHlwIjoidXNlciJ9.ZnWatLRzzb3EMo5VVEes-3wzhD3ePJpqt02zqyGnmSs" } ```

deekerman commented

2026-02-28 03:40:25 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Nov 19, 2024):

Interesting.
So not really exceeding the limit...

@CommanderStorm commented on GitHub (Nov 19, 2024): Interesting. So not really exceeding the limit...

deekerman commented

2026-02-28 03:40:25 -05:00

Author

Owner

@julianbraasch commented on GitHub (Aug 18, 2025):

Any updates on this?

@julianbraasch commented on GitHub (Aug 18, 2025): Any updates on this?

deekerman commented

2026-02-28 03:40:25 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Aug 18, 2025):

I have no clue where this is coming from.
If you have the time, adding running a debuggoer and looking where this fails would be the way to go.
Without having access to the concreate data, debugging this is impossible on my end.

@CommanderStorm commented on GitHub (Aug 18, 2025): I have no clue where this is coming from. If you have the time, adding running a debuggoer and looking where this fails would be the way to go. Without having access to the concreate data, debugging this is impossible on my end.

deekerman commented

2026-02-28 03:40:25 -05:00

Author

Owner

@julianbraasch commented on GitHub (Aug 23, 2025):

Wouldn't the first step be to investigate why 0 is not an allowed value for the status code dropdown? This does not require concrete test data. I'm really no expert with Node/web development in general unfortunately.

@julianbraasch commented on GitHub (Aug 23, 2025): Wouldn't the first step be to investigate why 0 is not an allowed value for the status code dropdown? This does not require concrete test data. I'm really no expert with Node/web development in general unfortunately.

deekerman commented

2026-02-28 03:40:25 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Aug 23, 2025):

You are confusing grpc-status and http status.

We don't currently let you check grpc status.
We might just look for OK, would need to check.

@CommanderStorm commented on GitHub (Aug 23, 2025): You are confusing grpc-status and http status. We don't currently let you check grpc status. We might just look for OK, would need to check.