Every project has a Logs tab with two views: Application logs (everything your container writes to stdout and stderr) and Request logs (HTTP requests routed through Brimble’s gateway). Both views live under one tab. Switch between them with the toggle in the header.Documentation Index
Fetch the complete documentation index at: https://paper.brimble.io/llms.txt
Use this file to discover all available pages before exploring further.
Application logs
Live stdout and stderr from your running container, plus a trend chart showing volume by level.Live tail
When you open the tab, Brimble streams new log lines as they’re emitted. Each line shows a timestamp, a level badge, and the message. Lines auto-scroll while you stay at the bottom; the auto-scroll pauses when you scroll up and resumes when you return to the bottom. Click any line to copy the formatted text to your clipboard.Levels
Brimble parses level out of structured log output and exposes a filter:| Level | Badge color |
|---|---|
error | Red |
warn | Orange |
info | Default |
debug | Faded |
info.
Trend chart
Above the log stream, a small chart bins log volume into time buckets and stacks the counts by level. Glance at it to spot:- Error spikes at a specific time, the red band climbs.
- Warning floods, sustained orange before issues escalate to errors.
- Quiet periods, mostly info, no red or orange.
Search and filters
- Search, free-text match against the log message; matches are highlighted.
- Date range picker, pick the window. The lower bound is capped at your plan’s log retention period (see Log retention).
- Advanced filters, scope by container instance, source, or other structured fields when present in your log lines.
Download
Click the export action (top right) to download the currently filtered logs as plain text. The file is namedapplication-logs-<project>-<range>.txt.
What’s logged
- Anything your service writes to stdout or stderr.
- Container start and stop events.
- Crash reports when the runtime kills a process (with reason code).
- Build logs, those live on the deployment, under Deployment history → Logs.
- Edge logs (Cloudflare requests that never reached your service), not user-visible.
Request logs
A table of HTTP requests that hit Brimble’s gateway and reached your service.Per-row columns
- Method, GET / POST / PUT / PATCH / DELETE, with a colored dot.
- Path, the request path.
- Status, the HTTP status the service returned, color-coded (green 2xx, orange 4xx, red 5xx).
- Response time, in milliseconds.
- Time, when the request happened (relative).
- Size, response body bytes.
Filters
- Method, dropdown for
GET,POST,PUT,PATCH,DELETE, or All Methods. - Status, dropdown for
2xx Success,4xx Client Error,5xx Server Error, or All Statuses. The status groups map to specific codes (2xxcovers 200, 201, 202, 204;5xxcovers 500, 502, 503, 504; etc.). - Date range, same picker behavior as application logs, capped by retention.
- Advanced filters panel, narrow by path prefix, status code range, response time range, or specific headers.
Detail drawer
Click any row to open a bottom-sheet drawer with two tabs:- Details, the request and response side-by-side. Headers, body preview, and metadata.
- Raw, the full raw request and response payloads as JSON, ready to copy.
Pagination
Request logs paginate cursor-style with Previous / Next controls in the footer. Date-range changes reset the cursor.Log retention
Logs are retained per plan. Older logs are aged out automatically; the date picker won’t let you pick a window before your retention boundary.| Plan | Application + request log retention |
|---|---|
| Free | 1 day |
| Hacker | 7 days |
| Pro | 14 days |
| Team | 30 days |
Database projects
Database projects don’t expose application or request logs through this tab. The engine’s own logs (slow query logs, connection logs, etc.) are visible inside the database with the engine’s standard tooling. For platform-level health on a database project, use Project metrics.Static sites
Static sites have request logs but not application logs, since there’s no container running. The request logs come from the edge serving cached and uncached asset requests.Troubleshooting
No logs streaming after the page loads. Check that your service writes to stdout or stderr (not directly to a file). Frameworks usually do this by default; logging libraries may need a console transport configured. Trend chart shows zero error volume but my service is failing. Confirm your service emits the literal stringerror (case-insensitive) or uses a structured logger that outputs a level field. Brimble parses both. If your logs are just exception traces without a level marker, they fall under info.
Date picker won’t go back further. You’re hitting the retention boundary for your plan. Upgrade for longer retention, or export important logs as you produce them.
Request logs missing for some traffic. Internal-network traffic between Brimble services (*.service.brimble.internal) doesn’t pass through the gateway and doesn’t appear in request logs. See Internal services.
Status code shown in dashboard doesn’t match my code’s response. Brimble’s gateway may have rewritten the response, for example a 502 for an unreachable container, a 401 for password-protected projects, or a 3xx for a configured redirect. The request logs show what the user saw, not what your service returned.
Next steps
- Project metrics, for CPU, memory, network, and response-time charts.
- Web analytics, for visitor-side analytics.
- Internal services, why internal traffic isn’t in request logs.