Fifteen minutes from an empty service to a first trace, metric, and log line landing in Helix, with no config file spelunking required.

Every Helix account starts the same way: an SDK install, an environment variable, and a service that has never emitted a span in its life. This is the fastest path from zero to a first signal.

1. Install the SDK

The Helix SDK auto-instruments the common frameworks (Express, Flask, net/http, Spring) and provides a manual API for everything else. Pick a runtime and install it as a normal dependency.

npm install @helix-obs/sdk
export HELIX_API_KEY=hlx_live_xxxxxxxxxxxx
export HELIX_SERVICE_NAME=checkout-api

2. Initialize before anything else runs

The single most common first-run mistake is initializing Helix after the framework has already required its HTTP library. Instrumentation patches modules on require, so the Helix import has to be the first line the process executes, before Express, before the router, before the database client.

// index.js - first line, no exceptions
require('@helix-obs/sdk').start({
  service: process.env.HELIX_SERVICE_NAME,
  environment: 'production',
});

const express = require('express');

3. Confirm the signal landed

Do not trust the dashboard yet, query it directly. This is also the query worth keeping close for every future integration, because whether the data arrived is the first question in almost every debugging session.

from traces
| where service.name == "checkout-api"
| where start_time > now() - 10m
| limit 20

If that returns rows, end-to-end trace ingestion is working. Metrics and logs follow the same pattern: the SDK batches and ships all three signal types over the same exporter, tagged with the same service.name and resource.attributes, which is what makes cross-signal queries possible later.

4. Tag the process, not just the request

Set deployment.version and host.name as resource attributes at startup rather than per-span. Every span, metric, and log from that process inherits them automatically, and a rollback investigation becomes a one-line filter instead of a join.

require('@helix-obs/sdk').start({
  service: process.env.HELIX_SERVICE_NAME,
  resourceAttributes: {
    'deployment.version': process.env.GIT_SHA,
    'host.name': process.env.HOSTNAME,
  },
});

Teams that skip this step usually add it back within a week, the first time a deploy causes a latency regression and nobody can tell which of the last three rollouts introduced it. Attaching the version once at boot means every span from that process carries the answer already, no need to cross-reference a deploy log against a trace timestamp by hand.

  • Initialize the SDK before any other require or import in the entrypoint file.
  • Verify ingestion with a direct HelixQL query, not the dashboard, in the first five minutes.
  • Set resource attributes once at process start, they propagate to every signal for free.
  • Next: write a first real HelixQL query, then wire a dashboard around it.