One defect per problem
A re-triggered monitor or recurring error comments on its existing Orbit bug instead of filing a new one. Status syncs both ways and the reporter is a person, never a shared integration account.
Orbit Pulse
Observability that files the bug for you
Logs, traces, errors, metrics, monitors, SLOs and incidents. OpenTelemetry first, with one Orbit bug per problem, kept in sync both ways.
Orbit Pulse
One defect per problem. Context in every alert. Permissions, not seats.
Pulse is observability for the teams already working in Orbit. Services send OTLP logs, traces and metrics, or JSON logs, with a project ingest key, and Orbit project permissions decide who sees telemetry. Telemetry is stored in ClickHouse with per-project retention, and every error and slow trace is kept. Browser real user monitoring and security detection rules are included. Session replay for your own front end, monitoring of your own databases and continuous profiling of your services are planned.
Why it is better
Why Pulse cuts the noise
Context in every alert
Recent Forge deployments, suspect commits and merge requests, correlated logs and traces, a runbook link and the owning team.
Low-noise defaults
Evaluation windows of at least 5 minutes, recovery thresholds, an explicit NO DATA state, cascade grouping and anomaly baselines that learn before they alert.
OpenTelemetry first, ClickHouse underneath
OTLP/HTTP intake with no proprietary agent, per-row TTL, batched durable writes and every error and slow trace retained.
Permissions, not seats
Orbit project permissions decide who sees telemetry. Usage by service and signal, cardinality limits and daily quotas warn early.
Database monitoring that keeps values at home Planned
For your own databases: query text is normalised on an agent in your network, plans are generic and never ANALYZE, and checks run in read-only transactions with timeouts.
Capabilities
What you get, group by group
Everything below is listed with its real status. Items with no badge are built and working today.
Built, no badgeIn development Built, in final testingPlanned Designed, not started
Intake and storage
OpenTelemetry first. No proprietary agent to adopt.
- OTLP/HTTP intake
Logs, traces and metrics in protobuf or JSON (gzip, deflate, zstd, br). Partial-success answers name the rejected records.
- JSON log intake
Any JSON log line. Common names for message, time, level, service, host, env, version and trace id are recognised.
- Project ingest keys
Created by project administrators, shown once, hashed and revocable, with rate and body limits.
- ClickHouse with per-project retention
Daily partitions and per-row TTL from 1 to 365 days, with batched durable writes.
- Daily quotas and usage
Quotas per day with an 80% warning and explicit rejection. A Usage page by service and signal.
Logs
- Log explorer with one query syntax
key:value, @attribute comparisons and ranges, wildcards, AND/OR/NOT, a histogram by status, facets with counts and precise syntax errors.
- Live tail and context
Live tail with the same filters. Log detail with attribute tree, trace link and surrounding logs.
- Saved views and CSV export
Saved views per project, click-to-filter from any attribute and bounded CSV export.
- Pipelines and log-based metrics
Remappers, a grok-style parser, exclusion rules with measured effect and metrics from logs.
1 more
- Pattern viewSimilar messages clustered with counts and drill-down.
APM and tracing
- Traces and rollups
Spans assembled into traces with HTTP and database semantics. Request, error and latency rollups with DDSketch quantiles.
- Service catalog and service page
Request rate, error rate and p50, p95, p99 per service and environment, endpoint table and versions seen.
- Trace explorer and waterfall
The same query syntax over spans. Logs correlate by trace id both ways.
- Service map
Derived from client/server and producer/consumer spans with edge statistics.
- Retention that keeps what matters
All error and slow traces are kept. The rest is sampled at your rate, and rollups stay complete.
Errors and Orbit bugs
One defect per problem, kept in sync with Orbit.
- Error grouping
Fingerprints from type and normalised application frames, with first and last seen, counts, versions and sample stack traces.
- Error lifecycle
Open, acknowledged, resolved and ignored. Resolve in a version, regressions reopen, custom fingerprint rules, merge and unmerge.
- One Orbit bug per problem
Create or link a bug from an error group through Orbit’s own create path, with the person’s permission.
- Two-way sync
Closing the bug resolves the error. A regression reopens or comments. The work item shows live counts.
Monitors and alerts
- Monitor types
Log count, APM error rate, latency and throughput, error tracking and metric threshold, with group-by, thresholds and a NO DATA policy.
- Durable evaluation
A leased evaluator keeps per-group state. Restarts never duplicate transitions or notifications.
- Notifications, mutes and downtimes
Templates, Orbit recipients, signed webhooks, scheduled downtimes and a runbook URL.
- Automatic Orbit bug on alert
One open bug per monitor and group. A comment on re-trigger, a comment or transition on recovery.
- Alert quality
Cascading failures grouped into one notification and a noisy-monitor report.
- Anomaly monitors
Each group is compared with its own baseline using median and MAD. Groups learn before they alert.
Metrics, dashboards and SLOs
- Metrics intake and explorer
OTLP gauges, sums and histograms plus a JSON series API. A cardinality limit with visible rejection.
- Dashboards
Timeseries, query value, toplist and log stream widgets with variables and JSON export and import.
- SLOs
On monitors or metrics, with error budget, burn rate and burn-rate alerts.
- CI metrics from Forge
Pipeline and job duration and failure rate, usable in monitors.
Incidents and synthetics
- Incidents
Declared from an alert or by hand with severity, commander, a timeline of alerts, notes and deployments, and linked Orbit work.
- Postmortems
Follow-up Orbit tasks from the incident and a link to a Folio postmortem page.
- Synthetic HTTP checks
Scheduled checks with assertions on status, latency and body, stored as metrics and usable in monitors.
Real users, replay and profiling
- Browser RUM
Core Web Vitals, JavaScript errors in the error groups and request timings joined to backend traces. Public client tokens with allowed origins.
- Session replay for your own front endPlanned
Masked by default in the browser, with sampling, record-on-error and a sandboxed player. Built for Orbit’s own web app; no recorder for your front end yet.
- Continuous profiling of your Go servicesPlanned
CPU, allocation, heap and goroutine profiles every minute, with flame graphs linked to Forge at the commit that ran. Built for Orbit’s own services; not yet available for yours.
Database and security monitoring
- Monitoring of your PostgreSQL databasesPlanned
Sessions every second with wait events and blocking trees, query statistics and inventory, with query text normalised on an agent in your network. Today this watches only Orbit’s own database.
- Query metrics, plans and activity for your databasesPlanned
Queries ranked by time, calls or load. Generic plans (never ANALYZE) grouped by shape. Trace database spans open the query.
- Recommendations and monitor templates for your databasesPlanned
Unused indexes, sequential scans, vacuum, long transactions and lock waits, with the SQL to apply.
- Security detection rules
Threshold and new-value rules previewed on recent data. Signals notify, file an Orbit bug and join incidents.
- Integrations catalog and agents for team databasesPlanned
A Connect wizard and agents in your network for MySQL, Redis, MongoDB, ClickHouse, queues and Prometheus.
- Pulse per organizationPlanned
Isolation of Pulse data per company site.
Forge and Lumen links
- Code links at the deployed SHA
Stack frames and spans open the file at the deployed commit, with your Forge permissions.
- Deployment tracking and release health
Deployment markers on charts and error rate and latency before and after each deployment.
- Suspect commits
Commits between releases, their merge requests and linked Orbit work for new or regressed errors.
- "What broke?" with Lumen
One cited answer from the incident, monitors, the deploy, its commits, related work and the runbook.
Compatibility and migration
Speak OpenTelemetry. Keep your instrumentation.
Pulse takes standard OTLP over HTTP, so the exporter you already run only needs a new endpoint and a project key.
OTLP/HTTP
Logs, traces and metrics in protobuf or JSON, compressed with gzip, deflate, zstd or br. Partial-success answers name the rejected records.
JSON logs
Send any JSON log line. Common names for message, time, level, service, host, env, version and trace id are recognised.
Monitoring for your databasesPlanned
Agents in your network watch PostgreSQL first, then MySQL, Redis, MongoDB and ClickHouse. Today Pulse watches only Orbit’s own database.
OTEL_EXPORTER_OTLP_ENDPOINT=https://<your-orbit-address>/otlp
OTEL_EXPORTER_OTLP_HEADERS=X-Pulse-Key=<project ingest key>
OTEL_SERVICE_NAME=checkoutPulse answers on the paths /otlp/v1/logs, /otlp/v1/traces and /otlp/v1/metrics. Placeholders in angle brackets are yours to fill in.
Works with the rest of Orbit
Pulse alerts carry their context
OrbitCreate or link an Orbit bug from an error group. The work item shows live counts and an incident’s follow-ups become tasks.Orbit ForgeDeployment markers, release health before and after, and stack frames that open the file at the deployed commit.Orbit FolioRunbook pages show live monitor state. A postmortem page is generated from an incident with its timeline.
What is next for Pulse
What Pulse will watch next
Next
- Pulse per organizationPlanned
Telemetry kept separate for each company site, needed before launch.
- Pulse screens in the redesigned interfacePlanned
Pulse moves to the redesigned interface after the Orbit screens.
Later
- Integrations for your own stackPlanned
- PostgreSQL for team databasesPlanned
- Prometheus, OpenMetrics and OTel CollectorPlanned
- MySQL and MariaDBPlanned
Pricing
Pulse is part of every plan
Pulse is on every plan. Retention is tied to your plan, and telemetry counts toward the shared storage quota at launch. The daily intake limit only protects the server and is not billed.
LimitFreeTeamBusinessEnterprise
Data retention3 days15 days30 daysContract
Daily intake100 MB2 GB10 GBContract
Storage per organization2 GB10 GB + 2 GB per paid user50 GB + 5 GB per paid userContract, from 500 GB
Know what broke, and who owns it
Orbit is in private preview. Every new organization will start with a 14-day Business trial, no card required.