How long does Supabase keep logs?

Retention depends on your plan, and on the free plan it is short — long enough for debugging, not long enough for an investigation. This matters because the gap between a breach happening and someone noticing is usually measured in weeks. If the logs that would explain it have already aged out, the investigation is over before it starts.

Is log retention a security problem or a cost problem?

Both, and they pull against each other. Longer retention costs more, so the natural move is to keep the window short — which is exactly the window an attacker benefits from. The way out is not to retain everything for longer, but to extract and keep the security-relevant subset: the events a detection rule matched, plus the incidents built from them.

Are Supabase log timestamps in my local timezone?

No — buckets are aligned to UTC boundaries. An hourly bucket starts on the hour UTC and a daily bucket at UTC midnight, so a 'day' in your analytics is a UTC day, not the viewer's day. Outside UTC, a chart rendered in local time without conversion will attribute events to the wrong day.

Does an empty bucket mean nothing happened?

Only if the bucket is actually present. A series that omits quiet periods makes 'nothing happened' and 'ingestion stopped' look identical, which is the difference between a calm night and a monitoring outage. A security feed should return zero-count buckets explicitly rather than skipping them.

Your Supabase logs expire. Your incidents don't.

Supabase gives you analytics over your project's logs — request volume, error rates, auth activity. It is genuinely useful for performance work. It is a poor fit for security work, for one structural reason: the retention window is shorter than the time it typically takes to discover a breach.

The retention gap

Industry breach reports have put the median time to detect an intrusion in the hundreds of days. Even the optimistic end of that range is measured in weeks. Now compare it against how long your platform logs live — on a free or entry-level plan, days. When you finally have a reason to look, the evidence has expired.

Upgrading your plan buys a longer window and a bigger bill, but it does not change the shape of the problem: you are paying to keep enormous volumes of routine traffic on the chance that a small part of it later turns out to matter.

Keep the signal, not the volume

The security-relevant fraction of your logs is tiny. Nearly every line is a successful request that will never matter. What matters is the subset a detection rule matched, and the incidents assembled from them — and that subset is small enough to keep for as long as you like.

This is why Defencecore stores normalized logs and the incidents built from them independently of your Supabase retention window. When an incident is opened, the log lines that triggered it are attached to it. They remain readable afterwards, even once the originals have aged out of Supabase.

Reading a volume chart without fooling yourself

Zero is data. An empty bucket must be rendered, not skipped. A gap where quiet periods have been omitted hides an ingestion outage perfectly.
The last bucket is incomplete. The current hour or day is still filling. Reading a dip at the right-hand edge as a decline is the most common misreading of any time series.
Buckets are UTC. Convert deliberately, and label which zone you are showing.
Detection lags ingestion.A bucket's flagged count can rise after the fact, as rules catch up with events already stored. A cached series goes stale.

What Defencecore adds

A volume series with the flagged subset drawn inside each bucket, so you can see what proportion of traffic tripped a rule rather than just how much traffic there was. All-time counts of stored logs, flagged events, and open incidents by severity and status. And because flagging is permanent, resolving an incident never rewrites the history of what matched — the rule did match those events, and the record says so.

Frequently asked questions

How long does Supabase keep logs?: Retention depends on your plan, and on the free plan it is short — long enough for debugging, not long enough for an investigation. This matters because the gap between a breach happening and someone noticing is usually measured in weeks. If the logs that would explain it have already aged out, the investigation is over before it starts.
Is log retention a security problem or a cost problem?: Both, and they pull against each other. Longer retention costs more, so the natural move is to keep the window short — which is exactly the window an attacker benefits from. The way out is not to retain everything for longer, but to extract and keep the security-relevant subset: the events a detection rule matched, plus the incidents built from them.
Are Supabase log timestamps in my local timezone?: No — buckets are aligned to UTC boundaries. An hourly bucket starts on the hour UTC and a daily bucket at UTC midnight, so a 'day' in your analytics is a UTC day, not the viewer's day. Outside UTC, a chart rendered in local time without conversion will attribute events to the wrong day.
Does an empty bucket mean nothing happened?: Only if the bucket is actually present. A series that omits quiet periods makes 'nothing happened' and 'ingestion stopped' look identical, which is the difference between a calm night and a monitoring outage. A security feed should return zero-count buckets explicitly rather than skipping them.