What causes "marking stale usage metrics as sent: %w" in crowdsecurity/crowdsec?

Check the Warningf log 'MarkStaleUsageMetricsAsSent: ' for the actual cause.

marking stale usage metrics as sent: %w

Error message

marking stale usage metrics as sent: %w

What it means

MarkStaleUsageMetricsAsSent gives up on metric rows received before the cutoff by setting their pushed_at, returning the number of updated rows. This error wraps a failing UPDATE; if the DB is fine but no rows match, updated is simply 0 with no error.

Source

Thrown at pkg/database/metrics.go:108

		return nil, fmt.Errorf("getting unsent usage metrics: %w", err)
	}

	return metrics, nil
}

// MarkStaleUsageMetricsAsSent gives up on metrics too old to be worth pushing, so a CAPI outage
// cannot leave a growing backlog behind. The rows live on until the age flush, for cscli.
func (c *Client) MarkStaleUsageMetricsAsSent(ctx context.Context, before time.Time) (int, error) {
	updated, err := c.Ent.Metric.Update().
		Where(
			metric.PushedAtIsNil(),
			metric.ReceivedAtLT(before),
		).
		SetPushedAt(time.Now().UTC()).
		Save(ctx)
	if err != nil {
		c.Log.Warningf("MarkStaleUsageMetricsAsSent: %s", err)
		return 0, fmt.Errorf("marking stale usage metrics as sent: %w", err)
	}

	return updated, nil
}

View on GitHub (pinned to 909b515798)

Solutions

Check the Warningf log 'MarkStaleUsageMetricsAsSent: <err>' for the actual cause.
Clear writer contention or enable WAL mode for the SQLite DB.
Free disk space and verify DB integrity.
Retry the cleanup — it's idempotent and will sweep remaining stale rows on the next run.

Example fix

// before
n, err := c.MarkStaleUsageMetricsAsSent(ctx, before)
if err != nil { return err }
// after: log-and-continue is safe
if err != nil {
    log.Warnf("stale metrics cleanup skipped this cycle: %v", err)
    return nil
}

Defensive patterns

Strategy: retry

Try / catch

n, err := client.MarkStaleUsageMetricsAsSent(ctx, cutoff)
if err != nil {
    log.Warnf("stale metric cleanup deferred to next cycle: %v", err)
    return nil // safe: operation is idempotent
}

Prevention

Treat cleanup as best-effort; it sweeps again next run.
Clear long-lived CAPI outages promptly to avoid huge stale backlogs.
Ensure disk headroom before large UPDATEs.
Check the underlying driver error in the warning log.

When it happens

Trigger: Calling MarkStaleUsageMetricsAsSent (pushUsageMetrics during a CAPI outage, or tests) when the bulk UPDATE fails: SQLite write-lock contention, disk full, corrupted DB, canceled context.

Common situations: Long CAPI outage followed by a large stale-cleanup UPDATE hitting a lock conflict with live agent writes; disk exhaustion after months of unpersisted usage metrics.

Related errors

AI-assisted analysis of crowdsecurity/crowdsec@909b515798 (2026-09-06). Data as JSON: /api/errors/c1f16ed70cb3ce70. Report an issue: GitHub.