Lago events ingested but events_count stays 0 in current usage API

TL;DR

The fix that worked for reporters: clear the Redis cache, or simply call the current_usage endpoint again, it refreshes its cache on read. The events are being counted; the usage endpoint serves a cached value that isn't invalidated at ingestion time.

Steps

1. The events are being counted; the usage endpoint serves a cached value that isn't invalidated at ingestion time. The fix that worked for reporters: clear the Redis cache, or simply call the currentusage endpoint again, it refreshes its cache on read. Per the maintainer, sending an event invalidates the cache for the associated charge/chargefilter, but the currentusage response cache only refreshes when you actually fetch currentusage, so fetch it after ingesting events.

When to use

You are seeing this: Events POSTed to /api/v1/events were accepted (returned a lagoid) and visible in the developer events UI, but the current usage API kept returning eventscount = 0 for a countagg billable metric (code chatnumber). Use this skill when you run into "Lago events ingested but events_count stays 0 in current usage API".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

Events POSTed to /api/v1/events were accepted (returned a lagoid) and visible in the developer events UI, but the current usage API kept returning eventscount = 0 for a countagg billable metric (code chatnumber).

In the thread Lago events ingested but eventscount stays 0 in current usage API, the question was: Events POSTed to /api/v1/events were accepted (returned a lagoid) and visible in the developer events UI, but the current usage API kept returning eventscount = 0 for a countagg billable metric (code chatnumber). Another user hit the same thing. The maintainer explained that with a single-worker setup, the currentusage cache isn't refreshed when events are ingested — it's only invalidated when the currentusage endpoint itself is called. The verified resolution: The events are being counted; the usage endpoint serves a cached value that isn't invalidated at ingestion time. The fix that worked for reporters: clear the Redis cache, or simply call the currentusage endpoint again — it refreshes its cache on read. Per the maintainer, sending an event invalidates the cache for the associated charge/chargefilter, but the currentusage response cache only refreshes when you actually fetch currentusage, so fetch it after ingesting events. Original discussion: https://vectle.com/threads/thrtAKYZ01PRmT1PeQ6bJMx0Q