Browse documentation

Investigate

Check rollout health

Connect feature exposure and releases to the customers and failures that followed.

Feature flags and releases are both delivery controls and investigation context. Use them to answer whether a change affected a specific customer or concentrated an Issue in the exposed audience.

Create and evaluate a flag

Open Explore → Feature Flags to create a boolean or multivariate flag. Give it a permanent key, then configure percentage, property, or cohort targeting. The key cannot be renamed after creation.

Keep a safe default for clients that cannot reach the decision endpoint. Activate a new flag only after testing a known matching and non-matching customer. Editing takes effect on subsequent SDK evaluations; cached clients can temporarily retain an earlier decision.

Evaluate with the customer ID and the properties used by targeting:

JavaScript / TypeScript

import { FlagsClient } from '@teml/sdk/analytics';

const flags = new FlagsClient({
  endpoint: 'https://api.teml.io',
  apiKey: import.meta.env.VITE_TEML_FLAGS_KEY,
});

await flags.reload('user_8842', { plan: 'pro' });
const showNewCheckout = flags.isFeatureEnabled('new-checkout');

Python

import os
import teml
from teml.feature_flags import FeatureFlags

events = teml.AnalyticsClient(
    endpoint='https://api.teml.io',
    api_key=os.environ['TEML_API_KEY'],
)
flags = FeatureFlags(
    endpoint='https://api.teml.io',
    api_key=os.environ['TEML_API_KEY'],
    capture=lambda event, props, distinct_id: events.capture(
        event, props, distinct_id=distinct_id
    ),
)
flags.reload('user_8842', {'plan': 'pro'})
show_new_checkout = flags.is_feature_enabled('new-checkout', 'user_8842')

Go

events := teml.NewAnalytics(teml.AnalyticsConfig{
	Endpoint: "https://api.teml.io",
	APIKey:   os.Getenv("TEML_API_KEY"),
})
flags := teml.NewFlags(teml.FlagsConfig{
	Endpoint: "https://api.teml.io",
	APIKey:   os.Getenv("TEML_API_KEY"),
	Capture: func(ctx context.Context, event string, props map[string]any, distinctID string) {
		_ = events.Capture(ctx, event, props, teml.WithDistinctID(distinctID))
	},
})
if err := flags.Reload(ctx, "user_8842", map[string]any{"plan": "pro"}, nil); err != nil {
	return err
}
showNewCheckout := flags.IsFeatureEnabled(ctx, "new-checkout", "user_8842")

The key needs project-scoped flags:read to call /api/v1/decide and analytics:write to record the exposure event. Add ingest:write only when the same client sends other telemetry. A browser key is visible to the browser user, and flags:read can read flag configuration through the current API. Treat flag keys, targeting rules, variants, and payloads as public client data; never store a secret in them.

Record exposure

Identify the customer before evaluating a flag. The SDK records the flag result with the active customer so it can appear in timelines and affected-customer analysis. If the decision request fails, keep the application’s safe default and surface the failure in application diagnostics; do not silently reuse an indefinitely stale decision.

Use stable flag keys and keep evaluation payloads small. Do not put secrets in flag payloads or customer properties.

Open Health on a flag to compare seven-day exposure counts, unique customers, and the observed variant distribution with the configured rollout. Health is based on SDK exposure events, not every raw evaluation. Low volume can make the distribution noisy.

Register a release

Record a deploy from CI so Teml can order Issues and regressions against a release:

teml releases create "$RELEASE" --commit "$GIT_SHA" --ref "$GIT_REF"

Use the exact same release identifier in the SDK and symbol uploads. Open Explore → Releases to compare new Issues, regressions, total error events, and affected customers, then open a release for its detailed blast radius.

Investigate a suspected regression

  1. Open the Issue or affected customer.
  2. Check the release and flag exposures immediately before the failure.
  3. Compare affected customers with customers on the previous release or control variant.
  4. Open a representative replay and trace.
  5. Disable or narrow the rollout only when the evidence supports it.

Avoid false conclusions

Exposure before a failure is correlation, not proof of cause. Confirm the changed code path in the trace, stack, logs, or replay before attributing the Issue to the flag.

Keep flags operational

Deactivate a flag before deleting it, and allow clients time to refresh. Remove stale flags after a rollout is complete. Long-lived inactive flags make investigation context harder to interpret and increase the chance of evaluating the wrong variant. Deleting a cohort used for targeting stops that cohort from matching; update the flag first.