Grafana

Where to sign in

	URL	Use it?
Grafana Cloud (current)	`https://brytebridge.grafana.net/`	Yes — logs (Loki), metrics (Prometheus), dashboards
AWS self-hosted (legacy)	`https://brytebridge.grafana.net/` (retired stack)	No — we operated Grafana, Loki, and Prometheus on AWS instances; that path is being turned off in favor of Grafana Cloud above

If you still have bookmarks or dashboards from the old AWS-hosted stack, move your day-to-day work to Grafana Cloud at the same workspace URL. New Fly log and metric pipelines land in Cloud, not on the old VMs.

Grafana Cloud is where we watch the health of our running systems—logs, metrics, and dashboards in one managed place instead of babysitting observability servers on AWS.

We are moving observability off self-managed AWS instances and onto Grafana Cloud, which gives us enterprise-grade retention and search without running Loki, Prometheus, and Grafana VMs ourselves.

What lives in Grafana Cloud

Grafana Cloud is not one tool—it is three roles that work together:

Piece	What it does	Plain English
Loki	Log storage and search	“What did the app print?” — stdout/stderr from Fly apps, searchable over time
Prometheus	Metrics storage	“Is it healthy and how busy is it?” — scrapes from each app’s `/metrics` and fleet collectors
Grafana	Dashboards and exploration	“Show me the story” — charts, panels, and investigations across logs and metrics

Logs → Loki. Health numbers → Prometheus. Viewing → Grafana.

Moving off AWS for observability

Historically, teams ran log and metrics stacks on AWS instances (agents, forwarders, disks to manage). That work is consolidating into Grafana Cloud:

Fly org log shippers send every app’s logs to Grafana Cloud—no per-repo log pipeline.
Org fleet monitor apps scrape /health and /metrics and push Prometheus data to Grafana Cloud.
API teams write normal logs and expose standard endpoints; platform owns the pipes into Grafana.

See [Fly.io](/fly/) for what each application must provide (/health, /metrics, stdout logging).

Staging

Staging Fly org → own shipper + scraper → Grafana Cloud (staging data)

UAT

UAT Fly org → own shipper + scraper → Grafana Cloud (UAT data)

Production

Production Fly org → own shipper + scraper → Grafana Cloud (production data)

Tiers stay separated in Fly and in observability—staging logs do not mix with production dashboards by accident.

What API teams do (and do not do)

You do:

Log to stdout / stderr (normal application logging).
Expose /health and /metrics (Prometheus format) on every Fly API.
Use prom-client and nstats on Node services (see Fly.io standards).

You do not:

Stand up your own Loki, Prometheus, or Grafana on AWS for a single API.
Wire per-app log agents or custom “send logs to S3 then grep” paths for routine deploys.
Manage Grafana Cloud org credentials in application repos (platform operates the collectors).

Sentry + Grafana (developing)

We use two complementary layers:

Layer	Best for
Grafana Cloud	Trends, logs, CPU/memory/request rates, fleet health, “what happened around 2:14 PM?”
Sentry	User-impacting errors, releases, stack traces, “this deploy broke checkout”

Cross-linking and alerting between Grafana and Sentry is on the roadmap—e.g. alert when error rates in Sentry correlate with metric spikes in Grafana, or route the right on-call signal to the right channel. Standards for those rules will be documented here as we turn them on.

Until then: Grafana for operations and logs; Sentry for errors and go-live sign-off.

Fly.io — org log shippers, metrics collectors, /health and /metrics
Sentry — production error observability and release health
AWS — we do not host routine API observability stacks there anymore
Fly checklist — promotion checklist per tier