Problem
A single day of the shared Hypercart log on binoidcbd production (hypercart-2026-05-27.log) was 432,527 lines / 64 MB, almost entirely one repeated message:
| Lines |
% |
Source |
| 423,232 |
97.9% |
hypercart-server-monitor INFO: Plugin initializing (every request) |
| 9,295 |
2.1% |
query_guard INFO: (Action Scheduler throttle observations) |
Sample:
[2026-05-27 00:00:00 UTC] hypercart-server-monitor INFO: Plugin initializing {"version":"0.4.28","php_version":"8.2.31","wp_version":"6.9.4"}
The shared log is effectively unreadable and grows ~64 MB/day, burying the signal (e.g. QueryGuard slow_query/query_killed events) in routine startup chatter.
Root cause
Production min level is correctly INFO (get_min_level() → WP_DEBUG ? DEBUG : INFO, filterable via hypercart_min_log_level). The flood is Server Monitor logging a per-request lifecycle event at INFO — a level that should be reserved for noteworthy events, not "the plugin booted." (The Helper's own Hypercart Helper loaded is at DEBUG — correctly suppressed in production.)
Proposed (logger-side guardrails — this repo)
- Repeat suppression / rate-limit — collapse identical consecutive entries (same plugin+level+message+context) within a short window into a single line with a count, so no single plugin can flood the shared file. (PHP's own error log does this with
message repeated N times.)
- Document the level contract — INFO = noteworthy/actionable; per-request lifecycle/boot events belong at DEBUG. Add to the integration guide so consumers self-police.
- Optional: a
hypercart_log_should_write filter so a consumer can cheaply drop known-chatty messages.
Companion fix (Server Monitor — separate)
The actual offender should stop logging Plugin initializing at INFO on every request — downgrade to DEBUG or remove. That plugin isn't a tracked repo here; cross-referencing so it isn't lost. The logger guardrails above cap the blast radius regardless of which consumer misbehaves.
Impact
High readability/cost win. With the offending INFO downgraded (or repeat-suppressed), the shared log drops from ~432k lines/day to a few thousand, and QueryGuard's warn/error events become findable.
Surfaced while validating the QueryGuard logging bridge (queryguard-plugin #7) — the goal there is a clean, single-location slow-query log, which this noise currently defeats.
Problem
A single day of the shared Hypercart log on binoidcbd production (
hypercart-2026-05-27.log) was 432,527 lines / 64 MB, almost entirely one repeated message:hypercart-server-monitor INFO: Plugin initializing(every request)query_guard INFO:(Action Scheduler throttle observations)Sample:
The shared log is effectively unreadable and grows ~64 MB/day, burying the signal (e.g. QueryGuard
slow_query/query_killedevents) in routine startup chatter.Root cause
Production min level is correctly
INFO(get_min_level()→WP_DEBUG ? DEBUG : INFO, filterable viahypercart_min_log_level). The flood is Server Monitor logging a per-request lifecycle event at INFO — a level that should be reserved for noteworthy events, not "the plugin booted." (The Helper's ownHypercart Helper loadedis at DEBUG — correctly suppressed in production.)Proposed (logger-side guardrails — this repo)
message repeated N times.)hypercart_log_should_writefilter so a consumer can cheaply drop known-chatty messages.Companion fix (Server Monitor — separate)
The actual offender should stop logging
Plugin initializingat INFO on every request — downgrade to DEBUG or remove. That plugin isn't a tracked repo here; cross-referencing so it isn't lost. The logger guardrails above cap the blast radius regardless of which consumer misbehaves.Impact
High readability/cost win. With the offending INFO downgraded (or repeat-suppressed), the shared log drops from ~432k lines/day to a few thousand, and QueryGuard's warn/error events become findable.
Surfaced while validating the QueryGuard logging bridge (queryguard-plugin #7) — the goal there is a clean, single-location slow-query log, which this noise currently defeats.