{{ message }}
Repository navigation
[BUG] <title>Pause monitoring due to issues with the number of monitored items #4447
Description
Is there an existing issue for this?
- I have searched the existing issues
Current Behavior
Pause monitoring. You can only pause up to 200 at a time.
Expected Behavior
Selecting any number of monitoring items can pause their monitoring behavior operations, not just 200.
Steps To Reproduce
No response
Environment
HertzBeat version(s):v1.9.0Debug logs
No response
Anything else?
No response
Activity
nihalritgithub commentedon Oct 13, 2026
Hi, I'd like to work on this issue.
I'll investigate where the 200-item limit is enforced and add a fix with regression tests.
Could you confirm whether the expected behavior is to support any number of selected monitors, or whether larger selections should be processed in batches?
mb7132 commentedon Oct 13, 2026
mb7132 commentedon Oct 14, 2026
If I have 1000 monitoring items, I would have to repeat the operation ten times to completely 'pause monitoring'. The 1000 monitoring items are divided into 5 groups of 200 each. First, select 4 pages, with a maximum of 50 items per page. After completing the 'pause monitoring' operation, then uncheck the 4 pages and select the next batch of 200. Repeating this step is very unfriendly.
solution：
Either 50 items per page become 100 monitoring items, or any number of monitoring items can be selected each time the "pause monitoring" operation is performed, instead of the current limit of 200 per batch
nihalritgithub commentedon Oct 14, 2026
Hi, I've traced the bulk pause failure to the monitor IDs being sent as query parameters. With larger selections, the request exceeds Tomcat's request-size limits and gets rejected before reaching the controller.
The current backend supports passing IDs in the JSON request body, and I've tested that approach successfully.
One thing I noticed is that the current React UI only supports selecting monitors from the current page, whereas the reported issue is on v1.9.0.
Would you prefer this to be addressed on the current master branch, including cross-page selection support, or should the fix specifically target the 1.9.x version?
mb7132 commentedon Oct 14, 2026
Suggestion: First fix for version 1.9.0, which can be used for a long time before the next version is released. Later, fix and merge for version 2. x
Thank you.
nihalritgithub commentedon Oct 14, 2026
Hi @Duansg, could you help confirm the appropriate target branch for this fix?
I've implemented a fix for #4447 against the v1.9.0 codebase. The issue was caused by monitor IDs being passed in the query string, eventually exceeding Tomcat's request-size limit.
The fix sends the IDs in the JSON request body while retaining query-parameter support for existing clients.
I've verified it against a running HertzBeat v1.9.0 server with 1, 200, 201, 500, and 1,000 monitors. All were paused successfully in a single request.
The reporter would prefer the v1.9.0 fix first. Should I open the PR against
release-1.9.0, or is there another branch intended for 1.9.x fixes?Thanks!
Duansg commentedon Oct 15, 2026
@nihalritgithub Thank you for asking. We have added the 1.9.1 branch.
[bugfix] Document bulk pause API and add E2E coverage (apache#4447)
[bugfix] Fix bulk pause for large monitor selections (#4447) (#4458)