`benecaster_feed_request_log_hard_cap_enforced`

Action Free Since v1.0.0

Fires from FeedRequestLogPurgeCron::maybe_enforce_hard_cap() whenever the emergency-purge guardrail deletes oldest rows from benecaster_feed_request_log. The guardrail runs as the first step of the nightly cron at 02:30: if the raw log row count exceeds benecaster_feed_request_log_hard_row_cap (default 5,000,000), the cron deletes the oldest rows until the count reaches 80% of the cap, then publishes a warning-level admin notice.

Use this action to route the guardrail firing to external monitoring or alerting (PagerDuty, Sentry, Slack) so operators know the raw log is growing faster than the configured retention window can drain it. Receiving this action is a signal to review the benecaster_feed_request_log_retention_days setting or the hard-cap value at Settings → Tools → Feed request log.

Parameters

Name	Type	Default	Description
`$event`	`array`	—	Guardrail event. Keys: `previous_count` (int — row count before trimming), `cap` (int — the configured hard cap), `target` (int — 80% of cap, the row count after trimming), `deleted` (int — number of rows removed)

Examples

Route the guardrail firing to PagerDuty

add_action( 'benecaster_feed_request_log_hard_cap_enforced', function ( array $event ): void {
    wp_remote_post( MY_PAGERDUTY_ENDPOINT, [
        'body' => wp_json_encode( [
            'routing_key'  => MY_PAGERDUTY_KEY,
            'event_action' => 'trigger',
            'payload'      => [
                'summary'  => sprintf(
                    'Benecaster feed log hit hard cap — deleted %d rows (was %d, target %d)',
                    $event['deleted'],
                    $event['previous_count'],
                    $event['target']
                ),
                'severity' => 'warning',
                'source'   => home_url(),
            ],
        ] ),
    ] );
} );

Notes

An admin notice is published automatically when the guardrail fires; this action is for external routing only. The notice re-surfaces every 7 days while the log remains above the cap (controlled by re_dismiss_after on the NoticeManager::publish() call).