Activity events, counters, and status semantics
Evidence first
Clear ownership
Verified next step
Read the bounded 28-day window
The summary aggregates a rolling 28-day period and stacks counts by event kind. Problems combine partial and failed outcomes. If a truncation notice appears, the chart reflects the bounded retained sample rather than all historical events.
Follow the newest-first event log
Events are grouped by calendar day and sorted newest first. The order helps reconstruct activity, but separate operations can overlap and completion order does not prove causal order.
Interpret fields and counters
| Field | Interpretation |
|---|---|
| Kind | The product operation that emitted the record. |
| Status | Recorded completion state, not business success. |
| Scope | The list, domain, campaign, or batch involved when known. |
| Processed | Items handled by the operation. |
| Failed | Items that could not complete successfully. |
| No data | Items with no usable result in that operation. |
| Skipped or duplicate | Items intentionally not processed again. |
Separate complete, partial, and failed
- Complete means the operation reached its recorded completion path.
- Partial means useful work may exist alongside failures or omissions.
- Failed means the operation recorded a failure outcome.
- A completed operation still requires output verification.
Show cost only with billing evidence
A cost line appears only when the event carries billing evidence. A missing cost does not by itself prove that every upstream action was free; use the owning feature and billing records for financial reconciliation.
Load older history safely
The page loads events in batches of 25 and preserves newest-first order. Search the correct workspace and load enough batches before concluding that an event does not exist.