SaaS Observability Without the Datadog Bill: A Seed-to-Series-A Stack

What gets shipped

The structured logger is the foundation. Every log line in production carries a stable baseline so that six months from now, the question "what was P99 latency for tenant acme on route POST /api/v1/run last Tuesday" is a SQL query, not an archaeological dig.

// lib/logger.ts
type LogLevel = "debug" | "info" | "warn" | "error";

interface BaseLogFields {
  ts: string;
  level: LogLevel;
  tenant_id?: string;
  user_id?: string;
  request_id?: string;
  route?: string;
  method?: string;
  status?: number;
  latency_ms?: number;
  msg: string;
  // Anything else lives in a free-form bag, not at the top level.
  fields?: Record<string, unknown>;
  err?: { name: string; message: string; stack?: string };
}

function emit(line: BaseLogFields): void {
  // Single JSON object per line. Platforms parse this natively.
  process.stdout.write(JSON.stringify(line) + "\n");
}

export function makeLogger(ctx: Partial<BaseLogFields> = {}) {
  return {
    info(msg: string, fields?: Record<string, unknown>) {
      emit({ ts: new Date().toISOString(), level: "info", msg, ...ctx, fields });
    },
    warn(msg: string, fields?: Record<string, unknown>) {
      emit({ ts: new Date().toISOString(), level: "warn", msg, ...ctx, fields });
    },
    error(msg: string, err: Error, fields?: Record<string, unknown>) {
      emit({
        ts: new Date().toISOString(),
        level: "error",
        msg,
        ...ctx,
        fields,
        err: { name: err.name, message: err.message, stack: err.stack },
      });
    },
  };
}

The handler wrapper attaches per-request context once and threads it through. Every line a handler emits from that point on carries the request ID, tenant ID, route, and method without the handler having to remember.

// lib/withObservability.ts
import * as Sentry from "@sentry/node";
import { makeLogger } from "./logger";
import { recordRequestMetric } from "./metrics";

export function withObservability<T extends (req: Request) => Promise<Response>>(
  routeName: string,
  handler: T,
): T {
  return (async (req: Request) => {
    const startedAt = performance.now();
    const requestId = crypto.randomUUID();
    const tenantId = extractTenantId(req);   // pulled from JWT or session
    const userId = extractUserId(req);

    const log = makeLogger({
      request_id: requestId,
      tenant_id: tenantId,
      user_id: userId,
      route: routeName,
      method: req.method,
    });

    Sentry.getCurrentScope().setTags({ tenant_id: tenantId, route: routeName });
    Sentry.getCurrentScope().setUser({ id: userId });

    try {
      const res = await handler(req);
      const latency = Math.round(performance.now() - startedAt);
      log.info("request handled", { status: res.status, latency_ms: latency });

      // Async, intentionally not awaited — metric write must not slow the response path.
      void recordRequestMetric({
        tenant_id: tenantId,
        route: routeName,
        method: req.method,
        status: res.status,
        latency_ms: latency,
        occurred_at: new Date(),
      });

      return res;
    } catch (err) {
      const latency = Math.round(performance.now() - startedAt);
      Sentry.captureException(err);
      log.error("request failed", err as Error, { latency_ms: latency });
      void recordRequestMetric({
        tenant_id: tenantId,
        route: routeName,
        method: req.method,
        status: 500,
        latency_ms: latency,
        occurred_at: new Date(),
      });
      throw err;
    }
  }) as T;
}

The metric tables are where the per-tenant story lives. Two tables: one for HTTP requests, one for LLM calls. Both append-only, both indexed for the queries you will actually run.

CREATE TABLE request_metrics (
  id            bigserial PRIMARY KEY,
  tenant_id     text NOT NULL,
  route         text NOT NULL,
  method        text NOT NULL,
  status        int  NOT NULL,
  latency_ms    int  NOT NULL,
  occurred_at   timestamptz NOT NULL DEFAULT now()
);

-- Partial index on the hot recent window. Older rows are still queryable
-- via the full table scan for ad-hoc analytics.
CREATE INDEX request_metrics_recent
  ON request_metrics (tenant_id, route, occurred_at DESC)
  WHERE occurred_at > now() - interval '14 days';

CREATE TABLE llm_metrics (
  id                bigserial PRIMARY KEY,
  tenant_id         text NOT NULL,
  model             text NOT NULL,
  prompt_tokens     int  NOT NULL,
  completion_tokens int  NOT NULL,
  latency_ms        int  NOT NULL,
  cost_usd          numeric(12,6) NOT NULL,
  occurred_at       timestamptz NOT NULL DEFAULT now()
);

CREATE INDEX llm_metrics_tenant_day
  ON llm_metrics (tenant_id, date_trunc('day', occurred_at));

-- Nightly rollup for finance queries.
CREATE TABLE tenant_usage_daily (
  tenant_id      text NOT NULL,
  day            date NOT NULL,
  request_count  bigint NOT NULL,
  error_count    bigint NOT NULL,
  p95_latency_ms int  NOT NULL,
  p99_latency_ms int  NOT NULL,
  llm_cost_usd   numeric(12,2) NOT NULL,
  PRIMARY KEY (tenant_id, day)
);

The rollup runs once a day, computes the percentiles using Postgres's percentile_disc aggregate, and writes one row per tenant per day. After that, every dashboard query hits tenant_usage_daily instead of scanning millions of raw rows. Finance gets a question like "which tenants cost us more than they pay" and the answer is a join, not a project.

The Sentry integration is the smallest piece of work and the biggest single quality-of-life gain. Wire it once in your bootstrap, set tracesSampleRate to something sane (0.1 at first, dial up if you need more visibility), tag exceptions with tenant_id and route from the handler wrapper, and let the free tier carry you for several months. The 5,000-errors-per-month cap is enough for a healthy app — if you are blowing through it, the problem is not the cap, it is the error volume.

Common failure modes

The first failure mode is logging strings instead of structured objects. Someone writes console.log("user " + userId + " hit error: " + err.message) and the platform captures it as a single text blob. Six months later when you want to filter by user_id, you are doing regex on a log archive instead of WHERE user_id = $1 on a table. The fix is a lint rule that forbids console.log in handler code and forces everything through the structured logger. Every log line is JSON, or it does not ship.

The second is writing metrics synchronously in the response path. The recordRequestMetric call in the wrapper above is intentionally void-prefixed and not awaited. If the metrics insert takes 30ms, you have added 30ms to every response in production. The metric write goes async, into a queue or a fire-and-forget promise, and if it fails it logs a warning and moves on. Observability that slows down the thing it observes is worse than no observability.

The third is the Netlify Functions 4 KB log truncation trap. Lambda compatibility mode on Netlify caps log output at 4 KB per invocation — anything beyond that is silently dropped, with only the last 4 KB retained. If your handlers log verbosely (full request bodies, full response payloads, nested debug objects), you lose data exactly when you need it most — during long, complex requests that are more likely to fail. The fix is to log lean by default and gate verbose logging behind a per-tenant or per-request debug flag.

The fourth is forgetting the single-user cap on Sentry free. Day one the founding engineer wires up Sentry under their email. Two months later the second engineer joins, cannot triage incidents because they have no account, and the team upgrades reactively in the middle of an outage. Plan for the $26/month Team plan as a Day-2 cost. It is a rounding error against the alternative of dropping issues on the floor because only one person can see them.

The fifth is letting the metric tables grow without a retention policy. request_metrics at 100 requests per second is 8.6 million rows per day. Without partitioning or a regular archive job, the table grows until query performance falls off a cliff. The fix is to partition by month (Postgres declarative partitioning works fine), keep 90 days of raw rows hot, and archive older partitions to cold storage if you need them. The tenant_usage_daily rollup is what carries the long-term reporting answers anyway.

The sixth is the tenant_id-on-every-row discipline failing silently. Engineers write a new endpoint, copy the boilerplate from an old handler, and forget to populate tenant_id in the log context because the new endpoint is unauthenticated (a public marketing page, a health check, a webhook). The logs all come through with tenant_id: null and the per-tenant queries quietly miss those events. The fix is a typed LogContext that distinguishes "no tenant for this route" (explicit) from "forgot to set tenant" (implicit) and a CI check that fails the build if the latter appears.

What this looks like in production

At BFEAI we run exactly this stack. Sentry handles the exception side at the paid Team tier (the free tier got us through the first few months). Netlify Functions logs cover request-level latency and status. A metrics schema in our Supabase Postgres carries request_metrics, llm_metrics, and a tenant_usage_daily rollup that powers the in-app admin dashboard. There is no Grafana, no Datadog, no Honeycomb. The total monthly observability bill is well under what most teams quote for a single Datadog seat.

The questions we answer from this stack in production: "what is P95 latency for tenant <X> on route <Y> over the last 24 hours" is a query against request_metrics filtered by tenant and route, computed with percentile_cont. "Which tenants ran more than $50 of LLM cost yesterday" is a query against llm_metrics grouped by tenant with a SUM(cost_usd) filter. "What error is spiking right now" is a Sentry dashboard, refreshed automatically. "Which endpoints regressed in latency this week" is a comparison of tenant_usage_daily.p95_latency_ms between this week and last week, joined on route. None of these required a third-party observability vendor.

The cost-per-tenant report is the one that pays for the whole exercise. Once a month, the rollup table gets joined against the billing table and produces a one-pager: tenant, MRR, infra cost, LLM cost, gross margin per tenant. Customers who are over-using the free tier or whose enterprise contract priced the LLM cost wrong show up immediately. The first time we ran it, two tenants accounted for 70% of LLM spend on $0 of revenue — both were trial accounts that someone had forgotten to expire. That single report paid for the metric tables for the next two years.

The Sentry-to-debugging loop is the second highest-value piece. An exception fires, Sentry tags it with tenant_id and route, the on-call engineer clicks through, sees the request payload, sees the user, sees the stack, and reproduces the bug in under five minutes. Compare against the "grep through CloudWatch / Netlify logs by timestamp and hope you find it" workflow, which is what teams without Sentry actually do. That delta — minutes versus an afternoon — is what Sentry buys you, and you get it at $0 for the first user and $26/month after that.

The thing that does NOT live in this stack: distributed tracing across many services. We have a small handful of services and a clear call graph, so tracing has not been worth the operational cost yet. If we grew to a dozen services with complex async paths, Honeycomb or a self-hosted OpenTelemetry collector would land on the roadmap. That is the inflection point — service count, not customer count — where the math on a dedicated tracing vendor starts to work.

When to actually upgrade to Datadog

The honest answer is two conditions, both required. First: past Series A, with revenue that can absorb a five-figure-monthly observability bill without it being a board topic. Second: a platform engineer or SRE on the team who specifically asks for it, with a written case for which problems it solves that the current stack does not. Either alone is insufficient.

Pre-Series A, the math does not work. The bill grows with engineers and infrastructure faster than revenue does in that phase, and the dashboards sit unused because nobody on the team has the spare cycles to build them. You pay for breadth you do not use, then you cancel after twelve months and feel bad about it.

Past Series A without a platform engineer asking, you are buying a tool you will not operate. Datadog (and Honeycomb, and New Relic) earn their keep when there is a human whose job is to make them pay off — building the dashboards, tuning the alerts, integrating with the rest of the on-call workflow. Without that human, the tool stays at the demo-quality config it shipped with, and the team continues to look at Sentry and Postgres for the answers they actually need. The bill just gets larger.

When both conditions are true, the upgrade is the right call. Distributed tracing across many services, deep APM with code-level profiling, multi-account log aggregation with sophisticated alerting — these are real problems Datadog solves well, and at the right scale they pay back. The pattern in this page is what gets you to that conversation with a clear head, on your own timeline, with the cost-per-tenant table that tells you whether you can afford it.

What to watch in your own implementation

Open your codebase and search for every place that calls console.log, console.error, or any unstructured logging primitive. Each one is a future query you cannot run. Pick the busiest handler first and route it through a structured logger with the baseline fields. Spread from there.

Then check whether tenant_id is on every log line that a handler emits. Add a typed wrapper around the request handler that requires you to declare a tenant context (or explicitly opt out for public endpoints), and let TypeScript fail the build if you forget. The cost of finding a missing tenant_id three months later is higher than the cost of the wrapper.

Pull up your Sentry account and check three things: who has access, what your error volume looks like against the 5,000-per-month free tier, and whether tenant_id is set as a tag on exceptions. If any of those needs fixing, fix them this week. Sentry is the single highest-leverage piece of the stack and it deserves an hour of your attention.

Finally, ask whether you have a metric table that can answer "what does each tenant cost us per day." If the answer is no, build one. Start with llm_metrics if you have AI features (the cost variance per tenant is highest there), or request_metrics if your infra cost is mostly compute. One table, one nightly rollup, one query. That report is the one that tells you whether your business model works at the customer-by-customer level, and it is the report that pre-empts the Datadog conversation by giving leadership a clearer picture than any vendor dashboard would.