Obervability for Pivot Platform Services

Frontend

PostHog

Plausible

Expo EAS Insights

Full Stack

Sentry

• Sentry is directly integrated into our frontend applications which push errors directly from client devices.

Rootly

• Incident management
• Status page for service health
• Alert aggregation from monitoring systems

Cloudwatch Metrics

While we don't use Cloudwatch logs or Container Insights, AWS sends infrastructure level metrics to Cloudwatch and Cloudwatch only for all deployed AWS services.

Axiom

We use Axiom as our ingest, storage, dashboarding, and monitoring tooling for logs, metrics, and traces.

ECS tasks publish OpenTelementry traces and the OpenTelemetry collector that runs as a sidecar in each Fargate task collects and ships those traces as well as task metrics to Axiom.

Each Fargate task is instrumented with a Fluent Bit sidecar using AWS FireLens to push stdout logs to Axion.

For third-party self-hosted services (NATS, Flipt) there is custom configuration needed at the OpenTelemetry collector level.

For the Next app, we use Axiom's Lambda-based log shipper to get logs from Cloudwatch to Axiom.

Axiom also supports other types of observability data ingest beyond OpenTelemetry, such as a direct integration with Cloudflare.

Rootly

We push alerts from Sentry and Axiom to Rootly, therefore covering both frontend and backend errors and latency spikes. Rootly manages our incident response workflow and status page.

Single-Tenant Deployments

When we deploy the Pivot Cloud Platform for a single organization, observability consists of pushing logs, metrics, and traces into our primary Axiom deployment with metadata to support filtering.

This lets us leverage one centralized incident management system in Rootly with alerts flowing from both Axiom and Sentry.