How Bolt Sight works.
What happens to a span between your code and the console: where it is checked, cleaned, stored and read, what is kept where, and how long.
The data flow
Services send OTLP to one endpoint with a project key. Bolt Sight cleans it on arrival and stores it per project. The console and the alert evaluator read from there.
Your services
Ingest
Node.js SDKWraps OpenTelemetry
Browser SDKWeb Vitals, page loads, API calls
Any OpenTelemetry SDKGo, Python, Java, .NET or a Collector
POST /v1/traces
POST /v1/metrics
POST /v1/logsBearer bsk_…OTLP receiver
- Protobuf or JSON, gzip optional
- 4 MB and 10,000 records per request
- Drops sensitive attribute names, redacts secret-like values
- Bounds attributes and log bodies
write
StorageTelemetryTraces, logs and metrics, stamped with the project
Project dataDashboards, alert rules, channels, API keys
query
rules, channels
Console and alertsConsoleInvestigate, Logs, Metrics, Dashboards, Errors, Services, Web Vitals
Alert evaluatorEvery 30 s; notifies webhook, Slack, email or Telegram
Follow one request
Six stages between your exporter and your screen.
- Export. Your SDK or Collector batches telemetry and posts it to
/v1/traces,/v1/metricsor/v1/logsover HTTPS as OTLP, protobuf or JSON, optionally gzip-compressed. The Node.js SDK exports metrics every 60 seconds by default. - Authenticate and admit. The receiver reads the
Authorization: Bearerkey, finds the project it belongs to, and for browser requests checks the origin against the project’s allowed origins. It then applies the request limits, the per-key rate limits and a check that the project has credits. Failures answer 401, 403, 413, 415 or 429, listed in the response codes. - Clean. Before anything is stored, attributes whose key contains a word such as
passwordortokenare dropped, values that look like credentials, emails or card numbers are replaced with[REDACTED], and sizes are bounded. The same cleaned records feed Live Tail, error grouping and alerts. - Stamp and store. The receiver stamps every record with the project of the key. Records are batched and written to the telemetry store; log lines are also published to Live Tail as soon as they are cleaned, without waiting for the batch. Data normally appears in the console within a few seconds of export.
- Read. The console asks the API for traces, logs, metrics and errors of the project you are in. Short windows read the raw tables; longer ones read pre-aggregated rollups (see below). Every query attempt is counted as usage.
- Alert. Every 30 seconds an evaluator loads the enabled alert rules, runs each rule’s query with a 10-second timeout, compares the result with the threshold and moves the rule through ok, pending, firing and resolved. It notifies the rule’s channels when the rule fires and when it resolves.
What is stored where
Two stores hold your data, and a third system holds your balance.
| Store | Holds | Notes |
|---|---|---|
| Telemetry store | A columnar analytics database (ClickHouse) holding spans, metric data points, log records, error events and service dependency edges, plus pre-aggregated rollups of them. | Every row carries the project it belongs to, stamped by the receiver from the ingest key. |
| Application database | A relational database (PostgreSQL) holding user accounts, project members, projects, hashed ingest keys, dashboards, saved queries, alert rules and their state and history, notification channels and service catalog metadata. | Passwords are stored as bcrypt hashes, refresh tokens and ingest keys as SHA-256 hashes, and channel secrets encrypted with AES-256-GCM. |
| Billing records | The credit balance, purchases and usage totals, kept by Techsstuff LLC’s billing system. | Bolt Sight reports counts per project (ingested records and query attempts), not telemetry content. |
Retention
These are the retention windows set in the product’s storage rules today.
| Data | Kept for | Detail |
|---|---|---|
| Traces (spans), logs, error events and service dependency edges | 8 days | Raw data is deleted by time-to-live rules on its timestamp. Log search windows reach back up to 7 days. |
| Metric data points | 90 days | Windows over 3 hours use 1-minute rollups for up to 7 days and 1-hour rollups beyond. |
| Daily totals behind the Events page | 400 days | Section, upsell, revenue and recommendation totals are pre-aggregated per day and kept longer than the raw events they come from. |
| Dashboards, alert rules, channels, keys, members | Until you delete them | Deleting a project or an account is requested by email; see the privacy policy. |
Metric resolution
Queries pick a source from the time window. Attribute filters always use the raw table, and the step is sized for at most 500 points per series.
| Time window | Source | Resolution |
|---|---|---|
| Up to 3 hours | Raw metrics table | Full resolution |
| 3 hours to 7 days | 1-minute rollup | 1-minute aggregates |
| Over 7 days | 1-hour rollup | 1-hour aggregates |
Limits and failure modes
What the service does when it is pushed, stated plainly.
| Ingest queue full | When a burst fills the receiver’s internal queue, the receiver drops the excess and counts it instead of growing without bound. Keep exporter batches below the request limits and give each producer its own key. |
|---|---|
| Usage and credits | Admission is checked against cached billing state that refreshes about every minute, and usage is reported about once a minute. A project can overshoot its balance by at most one reporting period. With no credits left, ingestion and queries pause until a pack is bought, and ingest requests answer 429. |
| Live Tail | Up to 100 concurrent Live Tail subscribers. A paused tail buffers up to 1,000 lines. |
| Availability | The service is run on a best-effort basis. This site makes no uptime or response-time commitment; the terms say the same. |