Use case · Background work
Cron and Action Scheduler workloads can delay queues, hold locks, call remote services, or consume resources without appearing as a normal page request. They need their own identity, capture policy, and safety limits.
This guide describes the intended public-v1 workflow. During pre-release, captures are founder-guided and every conclusion remains limited by the trace’s reported capabilities, completeness, and supporting evidence.
Where WP Flame fits
The investigation
Cron and Action Scheduler workloads can delay queues, hold locks, call remote services, or consume resources without appearing as a normal page request. They need their own identity, capture policy, and safety limits.
Tool boundary
Host-level metrics are often the best view of total resource pressure. WP Flame’s narrower intended role is to expose supported WordPress spans inside a specific eligible job and retain evidence that can be handed to the owning plugin developer.
Controlled capture plan
Useful output
A graph is supporting detail. The useful outcome is a measured opportunity, the evidence behind it, a safe action, and a way to verify the result.
Supported cron, CLI, or Action Scheduler context rather than a generic background-request label.
Supported callbacks, queries, HTTP calls, lifecycle activity, and ownership within the captured job.
Capture expiry, dropped spans, trace truncation, and persistence state needed to judge whether evidence is complete.
Measurement boundaries
Developer or client handoff
Continue the investigation
Current route to release
The paid design-partner programme pairs controlled captures with founder-led review while the public release gates are completed.