Crash Analytics & Query Monitoring
Pulsabase includes a built-in crash analytics and query monitoring system powered by ClickHouse — no third-party service required. Every API request is automatically instrumented, and errors are grouped, trended, and available directly from the Dashboard.
What’s Automatically Tracked
Section titled “What’s Automatically Tracked”Pulsabase instruments every request through pulsabase-core and pulsabase-edge via OpenTelemetry (OTLP). The data pipeline is:
pulsabase-core / pulsabase-edge └── OTLP gRPC → pulsabase-metrics-writer → ClickHouseSuccessful queries and errors are written to separate tables optimized for analytics (high-ingestion OLAP workloads).
Error Categories
Section titled “Error Categories”| Category | Source | Description |
|---|---|---|
QUERY_ERROR | pulsabase-core | Database query failures (SQL errors, timeouts, bad DSL) |
VALIDATION_ERROR | pulsabase-core | Input validation failures before query execution |
AUTH_ERROR | pulsabase-idp / pulsabase-auth | Authentication/authorization failures (invalid JWT, expired token, RLS denied) |
STORAGE_ERROR | pulsabase-storage | File upload/download errors, ACL policy denials |
EDGE_ERROR | pulsabase-edge | Edge function runtime errors (step failures, timeouts, HTTP errors in steps) |
SCHEMA_ERROR | pulsabase-core | Schema sync failures |
Dashboard Views
Section titled “Dashboard Views”Query Analytics → Crash Analytics
Section titled “Query Analytics → Crash Analytics”Dashboard → Query Analytics → Crash Analytics shows:
- Error rate over time (last 1h / 24h / 7d / 30d)
- Top issues — errors grouped by fingerprint (error type + message + stack trace)
- Issue list with:
- Error message and type
- Number of occurrences
- Affected users (if authenticated)
- First seen / Last seen timestamps
- Status:
unresolved/resolved/ignored
Issue Detail View
Section titled “Issue Detail View”Click any issue to see:
- Full error message and stack trace (for edge function errors)
- Sample request payloads that triggered the error
- User and session context
- Error frequency chart over time
- Breadcrumb events leading up to the error
Query Analytics → Queries
Section titled “Query Analytics → Queries”Dashboard → Query Analytics → Queries shows:
- Total requests, success rate, error rate
- P50 / P95 / P99 latency by table and action
- Slowest queries — sorted by average duration
- Per-table breakdown: which tables are accessed most, with what actions
Query Analytics → Performance
Section titled “Query Analytics → Performance”Dashboard → Query Analytics → Performance shows:
- API request volume over time (per hour/day/week)
- Query throughput (queries per second)
- Latency heatmap
- Anomaly detection: spikes in error rates or latency
Error Resolution Workflow
Section titled “Error Resolution Workflow”- Browse Crash Analytics → Issues to find active issues
- Click an issue to see the detail view — request context, stack trace, affected users
- Once fixed, mark it as Resolved (it moves out of the active view)
- If the same error re-occurs, it automatically reopens the issue (“regression”)
- You can Ignore recurring known issues that are acceptable
Retention
Section titled “Retention”| Data Type | Retention | Notes |
|---|---|---|
| Query success metrics | 90 days | Aggregated hourly after 7 days |
| Query errors / crash groups | 90 days | Full resolution for last 7 days |
| Hourly rollups | 1 year | For long-term performance trending |
Privacy & Data Sensitivity
Section titled “Privacy & Data Sensitivity”Pulsabase does not log the content of row data in metrics. The following is never stored in the analytics pipeline:
- Values of
INSERT/UPDATEpayloads - Row data from
SELECTresults - JWT token values
Only the following query metadata is stored: table name, action type, duration, status, error message/type, and user ID (hashed sub).