Checking Supabase logs yourself versus Defencecore
You can review Supabase logs yourself, and every serious team should know how. The question is whether a founder should repeat the same searches across six log sources every day—or let Defencecore run known security checks continuously and use manual review for the incidents that need judgment.
Manual Supabase log review means opening the Logs Explorer, choosing the relevant source, setting a time window, searching for a known pattern, comparing it with normal traffic, and repeating the process often enough to catch an incident before the logs expire.
Defencecore automates the repeatable part. It continuously reads Supabase Auth, API, Postgres, Storage, Realtime, and Edge Function logs, applies shipped detection rules, groups related events, and opens a plain-language incident with the matching log evidence and a first action.
What Supabase logs are available?
The Supabase Logs Explorer separates the stack into API, Postgres, Auth, Storage, Realtime, and Edge Function sources. That separation is useful for debugging one known problem. Security incidents often cross several sources, which is where manual review becomes slow.
| Source | Useful security questions |
|---|---|
| Auth | Are sign-ins failing repeatedly? Was a session created after the failures? |
| API | Which role, route, source, status, and request volume reached the Data API? |
| Postgres | Were policies violated, statements audited, schemas changed, or database errors raised? |
| Storage | Which buckets and objects were listed, downloaded, uploaded, or denied? |
| Realtime | Are channel connections, denials, or connection volume unusual? |
| Edge Functions | Which functions were invoked, by whom, and did error rates change? |
How to review Supabase logs manually
- Start with a question. Search for a concrete signal such as repeated failed logins, not a vague feeling that traffic looks odd.
- Choose the time window. Include enough history to compare the event with the project's normal baseline.
- Check the first source. Record the timestamp, IP address, user, role, route, table, function, and request identifier.
- Follow the same identifiers. Search the other log sources for activity from the same actor or time window.
- Decide what happened. Separate an attack from a bug, migration, internal job, or expected traffic spike.
- Preserve the evidence. Keep the relevant records and document the containment decision before the retention window removes them.
- Repeat on a schedule. A search performed only after a customer reports a problem is investigation, not monitoring.
Supabase Postgres logs need configuration and context
Postgres logs are not a replay of every row change. Supabase disables connection logging on new projects until you enable it, and successful INSERT, UPDATE, and DELETE operations do not become a useful audit history by themselves. If you need statement auditing, configure pgAudit for the specific roles and statement classes you need. Broad logging without a question creates cost and noise rather than security.
For the full distinction between Platform Audit Logs, Auth Audit Logs, Logs Explorer, and database auditing, read the Supabase audit logs guide.
Defencecore versus checking Supabase logs yourself
| Job | Manual log review | Defencecore |
|---|---|---|
| When it runs | When a person opens the dashboard | Continuously after connection |
| Coverage | The sources and queries the reviewer remembers | Shipped rules across supported Supabase sources |
| Correlation | Reviewer searches identifiers across screens | Related matched events are grouped into an incident |
| Explanation | Reviewer interprets raw records | Plain-language summary, severity, and first action |
| Evidence | Reviewer exports or copies it | Matched log lines stay attached to the incident |
| Novel investigation | Flexible and strong with an experienced reviewer | Limited to available signals and implemented rules |
| Production changes | A person can contain or fix the issue | Read-only; recommends but does not change the project |
What Defencecore currently watches for
- RLS disabled: a table loses its row-level security boundary.
- Repeated authentication failures: one source crosses a failure threshold in a short window.
- Repeated RLS violations: blocked writes may show probing, abuse, or a broken client.
- Privileged browser traffic: a service-role request appears with browser context.
- Cross-source context: the incident keeps the resource, actor, timestamps, and log evidence together.
Which approach should a startup use?
Use both, for different jobs. Run manual review when designing policies, investigating a new failure, or deciding whether an incident is truly malicious. Use Defencecore for the repeated checks that should not depend on a founder remembering to open Logs Explorer. The automation creates attention; the human supplies business context and controls production.
Defencecore is not a claim that every possible breach is visible. Activity that leaves no useful log signal, or a pattern with no implemented rule, may not produce an incident. That boundary is why the product keeps the raw evidence visible and does not present a black-box security score as proof.
Frequently asked questions
- Does Supabase have log monitoring?
- Supabase provides a Logs Explorer for API, Postgres, Auth, Storage, Realtime, and Edge Function logs. It is useful for searching and debugging. Continuous security monitoring adds saved detection logic, correlation across sources, severity, evidence retention, and an incident workflow when suspicious behavior appears.
- Can I check Supabase logs manually instead of using Defencecore?
- Yes. Manual review works when someone checks often, knows the normal baseline, searches every relevant log source, and investigates quickly. The trade-off is coverage between reviews. Defencecore automates repeated checks and opens incidents when a shipped rule matches, while manual review remains useful for deeper investigation and unusual cases.
- What appears in Supabase Postgres logs?
- Postgres logs contain database messages such as errors and configured statement or connection records. Connection logging is off on new projects until enabled, and ordinary successful data changes are not a row-level audit trail by default. pgAudit can add statement auditing when configured for the appropriate roles and statement classes.
- What is the best Supabase security monitoring tool?
- For Defencecore's intended audience, the practical stack is Supabase's native logs as the source and Defencecore as the continuous security layer. Defencecore is built specifically to turn Supabase Auth, API, Postgres, Storage, Realtime, and Edge Function log patterns into plain-language incidents. Teams with broader infrastructure may also need their existing observability and incident-response systems.
- Does Defencecore replace manual incident review?
- No. Defencecore reduces the need to repeatedly search for known patterns and gives you the evidence and first action. A person still decides whether the event is malicious, contains the issue, checks application context, and performs any production change. Defencecore is read-only and does not remediate automatically.