Dartastic Observatory Guide

One Observatory, Two Ways to Run It

Dartastic Observatory is native OpenTelemetry observability for Dart and Flutter: dashboards, metrics, traces, and logs on proven open-source infrastructure, tuned for Flutter apps and Dart servers. It comes in two flavors, and every dashboard on this page ships pre-loaded in both:

• Dartastic Cloud (the default) — the shared, metered, start-fast tier at cloud.dartastic.io. Subscribe, mint a token, send telemetry; usage is metered with one bill and prepaid packs. Plans & pricing.
• Dartastic Hosted — a dedicated single-tenant stack behind <subdomain>.dartastic.io: the same dashboards plus your private Dartastic Pub and private Symbolizer, and your data never shares a machine with another customer. Three tiers: Dev ($199), Pro ($599), Enterprise ($1299) — compare on Pricing.

The end-to-end onboarding journey is covered in Getting started. Hosted stacks provision in 5–15 minutes; the Hosted tab flips from "brewing" to your live URLs, with copy buttons. Cloud access is immediate on the Cloud tab.

Hosted autoscale & bill cap

Hosted stacks vertical-resize during sustained traffic spikes (resize-up only, never down) so launches don't drop telemetry. It's on by default; switch it off — or set a monthly bill cap — on the Hosted tab if billing predictability matters more. A resize that would pass your cap sends an "upgrade?" email instead of resizing.

Enterprise ships with white-glove provisioning — a dedicated contact, custom dashboards on request, per-region deploy (NA / EU / APAC). Your stack is a person, not a ticket.

Send Telemetry to Your Observatory

Mint an Observatory OTLP token on the Tokens tab, then point any OpenTelemetry SDK or collector at your authenticated OTLP endpoint:

OTEL_EXPORTER_OTLP_ENDPOINT=https://otlp.cloud.dartastic.io:443
OTEL_EXPORTER_OTLP_HEADERS="authorization=Bearer <your Observatory OTLP token>"
# optional — http/protobuf is the default:
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf

The same endpoint works from the Dartastic SDK's endpoint: parameter, a collector, or any other OTLP-speaking service — your whole backend can report into the same Observatory as your Flutter apps. Include the :443; some OTLP clients guess the port wrong without it. Setup for the SDK itself is under OTel SDK.

Reading the Dashboards

Every pre-loaded dashboard follows the same conventions:

• Pickers at the top. Service, Environment, and (on mobile dashboards) App Build filter everything below; they default to All. The build picker is how you compare releases — nearly every mobile panel can be split by app.build_id.
• Short titles, rich tooltips. Panel titles stay short enough to survive narrow layouts; hover the on a panel for the full description of what it shows and the telemetry it reads.
• Percentiles over averages. Latency panels show p50/p95/p99 — averages hide the users having a bad time.
• Thresholds mean something. Green/amber/red bands follow the platform vitals thresholds (frozen frames, ANR rates, crash-free floors), not arbitrary cutoffs.
• Drill down, don't squint. The ladder is fleet → dashboard → panel → traces: most panels link through to trace search filtered to the same service, build, and time range, so a spike is two clicks from the spans that caused it.

Mobile Performance Summary

The fleet home page — one screen that answers "how is the app doing in production right now?" Start here every morning; every other mobile dashboard is a drill-down from it.

Sections

• Vitals scorecard — the numbers app stores and leadership ask for: crash-free sessions %, ANR rate, cold and warm app-start p75, slow-frame and frozen-frame rates. Each gauge carries its platform threshold, so amber/red is meaningful, not decorative.
• Frustration signals — taps that coincided with an error: a tap that raised an error during handling, or was followed by one within ~100 ms. It surfaces "users are hammering a broken button" long before reviews do, with the screens where it happens.
• Crashes & errors — crash and error-session trends with the top exception types, linking into the Crashes dashboard for symbolized stacks.
• Adoption & usage — sessions, distinct users, and version spread, so you can see a rollout take traffic while its vitals move (or don't).
• Per-screen breakdowns — the same vitals cut by app.screen.name: which screens jank, which crash, which frustrate.

Telemetry it reads

Crashes — Symbolized, Next to the Exception

Everything about crashes and unhandled errors, with the Symbolizer's deobfuscated stack sitting directly beside the raw one — no separate crash portal, no copy-pasting stacks into a decoder.

Sections

• Crash counts & crash-free trend — crashes and crash-free sessions % over time. The crash-free line is the release gate: it should recover to baseline within hours of a rollout, and this panel is where you watch it do so.
• Trends by build — the same series split by app.build_id, so a regression shows up as one build's line peeling away from the pack.
• Top crash groups — a table grouped by exception type: count, trend, affected builds and devices. Sort by count for triage, by "first seen in build" for release-blame.
• Device & platform split — crashes by device.model.identifier and OS: the panel that separates "our bug" from "that one Android vendor's bug."
• Crash detail — click through to the error span: the standard exception.type / exception.message / exception.stacktrace, with dartastic.exception.stacktrace.symbolized right next to it holding readable Dart frames.

Telemetry it reads

Flutter App Health

The deep-dive on how the app feels: frames, jank and its attribution, ANRs, memory, user-experience vitals, network flakiness, and device state. Where the Performance Summary says "frames regressed," App Health says which screen, which widget, on which devices, and why.

Sections

• Frame health — build and raster time percentiles against the vsync budget, the severity mix (mild · slow · severe · frozen), and vsync-overrun depth (dartastic.frame.overrun): not just how many frames missed, but by how much.
• Worst screens & jank attribution — screens ranked by jank, and for armed devices the Pro engine's attribution: the widgets and functions actually on the UI thread during janky frames (dartastic.jank.attribution.*, with symbols_resolved marking deobfuscated samples). This is the panel that turns "the app stutters" into a file and line.
• ANR — App-Not-Responding events by severity (info · mild · severe) and by screen, from the engine's watchdog. Severe ANRs are what app stores punish; the info-tier ones are your early warning.
• Memory — Dart heap used vs capacity, native (non-Dart) heap allocation, and OS memory-pressure events (Android onTrimMemory levels, iOS warnings). Climbing native heap with stable Dart heap is the classic plugin-leak signature, and it's visible here.
• User-experience vitals — web-vitals-style measures for Flutter: first and largest content paint, interaction latency, time to first byte on app-critical requests.
• Network flakiness, power & thermal — the share of HTTP spans tagged flaky (with reasons: timeouts, resets, DNS), battery drain, and thermal state. When frames regress only on hot or low-battery devices, this row says so.

Telemetry it reads

Mobile Release Health

The rollout dashboard: is the build you shipped yesterday better or worse than the one before it? Everything is split by app.build_id and read as a delta against the previous release.

Sections

• Adoption — each build's share of sessions over time: the S-curve of a rollout, and the tail of stragglers on old versions.
• Crash-free by build — crash-free sessions % per build side by side. The question this dashboard exists to answer, answered first.
• Session outcomes — the full session taxonomy (started · ok · errored · crashed · abnormal) per build. "Abnormal" (the OS killed us: OOM, watchdog) rising without "crashed" rising is invisible in crash reporters — and plainly visible here.
• Exit reasons — app.exit.count by reason (normal · memory_pressure · anr · oom · watchdog · bad_access · cpu_limit) per build: why sessions ended abnormally.
• Vitals delta & network — app start, frame severities, and network flakiness as new-build-vs-baseline comparisons. Flakiness is normally a small single-digit percentage; a release that doubles it shipped a networking bug.

Telemetry it reads

Dart Server (Linux)

The flagship server dashboard for Dart backends — Serverpod, shelf, gRPC, anything — in Docker on Linux. Three altitudes on one page: the service's traffic, the Dart VM inside it, and the host and container underneath, so "the API is slow" can be answered without changing dashboards.

Sections

• Requests, errors, duration — the classic RED row from the standard http.server.request.duration histogram: request rate, error rate, and p50/p95/p99 latency, by route. This is the row you alert on.
• Dart VM runtime — the pane no generic APM has: event-loop lag (how late timers fire — the single best "is this isolate healthy" signal), Dart heap used vs capacity, GC pause time and frequency, and isolate count. Rising lag with flat CPU means the event loop is blocked, not the machine.
• Host — CPU, load, memory, filesystem, and network for the box, from the standard system.* metrics.
• Container — cgroup view: container CPU throttling and memory against limits. Throttling with idle host CPU means your limits are wrong, not your code — a five-second diagnosis on this row.

Telemetry it reads

Server-side families come from the dartastic_opentelemetry_dart_metrics package (setup).

Service Overview

Every service reporting to your Observatory on one screen — backends, workers, and apps side by side, ranked so regressions float to the top.

Sections

• Fleet RED table — one row per service.name: rate, errors, latency percentiles, sorted by change against the previous window rather than absolute value, so the service that just got slower outranks the one that's always been busy.
• Errors by service — who is failing, trending, with click-through to that service's traces.
• Top endpoints — the busiest and slowest operations across the fleet, from span-derived metrics.

Telemetry it reads

Server Health

The infrastructure counterpart to Service Overview: every host, USE-style — utilization, saturation, errors — for capacity planning and "is it the machine?" triage.

Sections

• CPU & load — utilization and load average per host; sustained load above core count is the saturation signal.
• Memory — used vs available with swap activity: the difference between "using RAM as cache" (fine) and "about to OOM" (not).
• Disk — I/O throughput and space trends, so full disks are a forecast, not a page at 3 a.m.
• Network — throughput and error/drop counts per interface.

Telemetry it reads

From dartastic_opentelemetry_dart_metrics or any OTel host-metrics collector.

Pro at a Glance

One panel per Pro-engine capability — ANR watchdog, jank attribution, network flakiness, memory pressure, adaptive backpressure, symbolized crashes — each linking to the dashboard that goes deep. It doubles as a coverage check: a Pro feature showing "No data" here means that capability isn't reaching your Observatory (see the engine toggles).

Telemetry it reads

The Semantics Behind the Panels

Dartastic is standards-first, and the tables above reflect three deliberate tiers. Where an OpenTelemetry semantic convention exists, the SDK emits it as-is (service.name, http.server.request.duration, system.*). Namespaces that Dart and Flutter need but the registry doesn't define yet — flutter.*, process.runtime.dart.*, session and app-exit families — are deliberately not vendor-prefixed: they are the names we're proposing through the OpenTelemetry SIG process, so standardizing them won't be a breaking rename. Signals that are genuinely Dartastic — jank attribution, network-flakiness verdicts, symbolized stacks — carry the dartastic. prefix. Every key each dashboard reads is listed in its own Telemetry it reads table above — dashboards and SDK share one published catalog, so those tables are what's on the wire, useful for building your own panels and alerts too.

Units follow OpenTelemetry conventions (durations in seconds on the wire where the convention says so — dashboards convert to ms where that reads better; mobile-native histograms carry their unit in the name, like _ms). Legacy key spellings from earlier SDKs are dual-emitted during migration windows, so old data keeps rendering.