Logs
Request logs
A calm, request-level view of what your backend is doing with Birdor. Use this when the Usage page tells you “something looks off” and you want the next layer of detail.
Logs are per-request entries across all projects in this workspace. Start here when you want to answer “what exactly happened to this call?”
Sample data · placeholder logs
Project:
Env:
Status:
Search:
Recent requests
The most recent calls from your backend to Birdor.
Time
Project
Tool
Env
Request
Status
Duration
2025-11-28 22:41:03
my-saas-prod · prod
POST /v1/tools/jwt/debug
200
92 ms
2025-11-28 22:38:17
my-saas-prod · prod
POST /v1/tools/json/diff
422
134 ms
2025-11-28 22:30:44
tools-service · staging
POST /v1/tools/base64/encode
200
67 ms
2025-11-28 22:18:09
playground · dev
GET /v1/tools/timestamp/convert
504
1500 ms
Showing sample entries. Real logs will be live-updating and filterable.
How to debug calmly
- Start on the Usage page to see if there's a broad spike in errors.
- Filter logs by project, environment, and status to find problematic calls.
- Use timestamps and paths to correlate with your own application logs or tracing system.
- Once you've understood the pattern, take a breath, fix it in code, and keep building.
What's stored here?
Birdor aims to store only what's needed to help you debug:
- Timestamp, project, environment, and tool.
- HTTP method, path, status code, and latency.
- Payloads may be truncated, hashed, or omitted depending on sensitivity.
See the privacy policy for details about retention and processing.
Exporting logs
For now, log export is not wired up in the UI. In the future, you'll be able to:
- Download a slice of logs as JSON/NDJSON.
- Pipe logs into your own observability stack.
If you're running into serious production issues and need temporary access to additional log detail, reach out and we'll see how we can help in a calm way.