Star on GitHubLogging
Searchable logging built in: every session, query, and error is captured and shown in the Insights log viewer, with detailed logging options you control at runtime.
Structured logging
Debugging with print statements is tedious, and adding a full logging stack usually requires setting up additional infrastructure and building a viewer to read the logs. Small teams put it off and pay for it during the next incident.
Serverpod logs each session's calls, queries, and exceptions to your own database and shows them in the Insights companion app or directly in Serverpod Cloud.
How it works
1Run your server
Every call is logged as a session: the endpoint, its database queries with timing, and any exceptions with their stack trace.
2Add your log entries
Log anything and set the log level.
session.log('Processing order $orderId', level: LogLevel.info);
3Filter it in Insights
Open Insights and quickly identify slow methods or failed calls. No setup required.
Session logging
Calls, queries, and messages are grouped by the request that produced them, so a single session tells the whole story of what happened.
Runtime log levels
When something breaks, change the log level on the running server and watch the details roll in, without redeployment. You can set log levels per endpoints or even per methods, saving valuable space in your database.
Query logging
Slow or unexpected database queries are logged with their execution time, making it easy to spot the query responsible for a slow endpoint.
Everything included
Why Serverpod
Works with
Serverpod Insights Postgres
Frequently asked questions
Does Serverpod log database queries?
Yes. Queries are logged with execution time, stack traces, and grouped by the session that ran them.
Where are logs stored?
In your own database. View them in the Insights log viewer.
Can I change log levels without redeploying?
Yes. Log levels are controlled through runtime settings that take effect on a running server.
Is the logging structured?
Yes. Entries are tied to sessions and endpoints, so logs are searchable rather than flat text.
When should I not use this?
For very high-volume aggregation across many services, forward logs to a dedicated platform. Built-in logging is per-server and stored in Postgres.