Skip to content
VEKTIS

Troubleshooting

This page covers issues on the VEKTIS dashboard side — Dev Items, baselines, post-release metrics, impact scores, and the integrations that feed them. For SDK-side issues (events not arriving, error codes in your browser console), see the tracker troubleshooting matrix.

If you’re not sure which side of the line your issue lives on, run vektis-troubleshoot first — it’ll tell you whether the SDK is at fault.

”I created Dev Items but I don’t see any metrics”

Section titled “”I created Dev Items but I don’t see any metrics””

Most likely cause: you haven’t added baseline data to the Dev Item yet, or you have automated tracking configured but no events have arrived for the matching feature_id yet.

What to check:

  1. Open the Dev Item and look at the Baseline Metrics section. If there are zero baseline data points, that’s expected — VEKTIS can’t show metrics until you’ve added some. See Collecting Baseline Data.
  2. Look at the data source. If the Dev Item shows a “manual” data source, you add baselines and post-release values yourself in the dashboard. If it shows an “automated” source, baseline values come from events your SDK reports — see the next scenario if those aren’t showing up.
  3. Check the feature_id matches what your code reports. Mismatched feature_ids (different capitalization, missing hyphens, etc.) are the most common reason events don’t arrive.

”I configured automated tracking but no events are reaching the Dev Item”

Section titled “”I configured automated tracking but no events are reaching the Dev Item””

Most likely cause: the feature_id on the Dev Item doesn’t match the feature_id in your vektis.track() calls, or the SDK isn’t actually reporting events.

What to check:

  1. Verify the SDK is sending events. In your app, open DevTools → Console and run vektis.getStatus(). You should see state: 'READY'. If state is 'DISABLED' or 'UNINITIALIZED', the SDK isn’t running — see the tracker troubleshooting matrix or run vektis-troubleshoot.
  2. Check the unmapped features banner on /dev. If your feature_id is in there, the events ARE arriving but no Dev Item is listening for them. Either the Dev Item’s feature_id is wrong, or you’re looking at a different Dev Item.
  3. Compare strings character-for-character. checkout-completed and checkout_completed are different. The dashboard’s feature_id and your code’s value must match exactly.
  4. Wait a few minutes. Events take a short time to be processed. If you just configured automated tracking, give it five minutes before assuming something’s wrong.

”My impact score didn’t calculate”

Section titled “”My impact score didn’t calculate””

Most likely cause: you have fewer than 2 baseline data points, or all your baseline values are identical.

VEKTIS needs to know what “normal” looks like before it can detect “abnormal.” With only one baseline value, there’s no spread to estimate normal fluctuation. With identical values, the spread is zero — the calculation has nothing to work with.

What to check:

  1. Open the Baseline Metrics section. If you see “Need more baseline data” instead of an impact score, add more baseline measurements. Aim for 4 or more.
  2. If your baseline values are all the same, that’s likely a measurement issue — the metric you’re tracking probably does fluctuate in reality, but you might be sampling it from a cached or rounded source. Check whether your data source updates between samples.
  3. Look at the burn-in option. If you don’t have any pre-release baseline data at all, VEKTIS will establish a baseline from your first 3 post-release measurements. The first 3 post-release values become the baseline; impact scores start appearing on the 4th.

See Impact Scores for the full reference.

”My baseline strength is yellow or red”

Section titled “”My baseline strength is yellow or red””

What it means: the strength indicator reflects how reliable your impact calculation will be.

Color / labelData pointsMeaning
Red — Insufficient0 or 1No calculation possible yet. Add more baselines.
Red — Weak2Bare minimum. The “normal range” is estimated from very little data — results may look more or less significant than they really are.
Yellow — Moderate3Decent calculation, but more data improves reliability.
Green — Strong4 or moreReliable picture of normal fluctuation.

What to do: add more baseline measurements before relying on impact scores. The right number depends on how volatile your metric is — if it bounces around a lot day-to-day, aim for 6–8 baselines spread across enough time to capture that variation. For stable metrics, 4 is plenty.

If your feature has already shipped and you can’t go back to collect more pre-release data, switch to the burn-in baseline approach — your first three post-release measurements become the baseline.

”I shipped, marked it released, but the Post-Release section is blank”

Section titled “”I shipped, marked it released, but the Post-Release section is blank””

Most likely causes:

  1. You haven’t added a post-release measurement yet. Marking the Dev Item as released sets the date but doesn’t record any data — that part is your call.
  2. Your automated feature_id isn’t matching events. Same scenario as the “no events reaching the Dev Item” case above.
  3. Your release date is too recent. Some metrics have lag (a daily-rollup conversion rate, for example, doesn’t have today’s number until tomorrow). Wait until your data source actually has post-release values.

What to check:

  1. Open the Dev Item, scroll to the Post-Release Metrics section, click Add Post-Release Metric, and enter a date and value from your data source. See Measuring After You Ship.
  2. If you set up automated tracking, verify the feature_id matches and check the unmapped features banner on /dev.

”Two Dev Items got the same feature_id” or “I picked the wrong feature_id”

Section titled “”Two Dev Items got the same feature_id” or “I picked the wrong feature_id””

A given feature_id can only route to one Dev Item per organization. The dashboard prevents you from creating a duplicate, but if you’ve already saved the wrong value:

What to do:

  1. Edit the Dev Item and change the feature_id to what you actually want.
  2. Update your code to call vektis.track() with the new feature_id value, or the events will become unmapped.
  3. Old events stay associated with the old feature_id. They don’t get retroactively re-routed. If continuity matters (e.g., you’ve already collected post-release data under the old ID), prefer keeping the old ID and renaming the Dev Item title instead.

See Feature IDs for naming rules and best practices.

”My PR suggestions stopped showing”

Section titled “”My PR suggestions stopped showing””

This now lives on the dedicated GitHub troubleshooting page. See GitHub troubleshooting — My PR suggestions stopped showing.

”An SDK event arrived but the Dev Item still says ‘no events yet’”

Section titled “”An SDK event arrived but the Dev Item still says ‘no events yet’””

Most likely cause: the events arrived under a different feature_id than the Dev Item is listening for, OR the Dev Item’s data source hasn’t been promoted from manual to automated yet.

What to check:

  1. Look in the unmapped features banner on /dev. If your feature_id is there, the events arrived but the routing isn’t matching.
  2. Open the Dev Item and check its data source. If it shows “manual” but you’ve configured automated tracking, the source needs to be promoted. This happens automatically on the next analytics sync — usually within a few minutes. If the Dev Item still shows “manual” after waiting, see the tracker install troubleshooting section.

”I get ‘Need at least 2 baselines’ but I have 2”

Section titled “”I get ‘Need at least 2 baselines’ but I have 2””

Most likely cause: one of your baselines was added with a date that’s after your release date, so it’s being treated as a post-release measurement. Or the value type changed mid-baseline and one entry is now incompatible.

What to check:

  1. Open the Baseline Metrics section. Verify all baseline dates are before your release date.
  2. Check the value type column. All baselines should have the same value type. If one is in a different unit, edit or delete it.
  3. Move any post-release values to the right section. A baseline measurement dated after release should be in Post-Release Metrics.

When to ask for help

Section titled “When to ask for help”

If none of the above apply, gather:

  • The Dev Item’s URL (so we know which one).
  • A screenshot of the section that’s misbehaving.
  • The full output of vektis.getStatus() from your app’s browser DevTools console.
  • The exact feature_id your code is reporting and the one configured on the Dev Item.

Then share feedback with that context — it’ll cut diagnosis time significantly.

Section titled “Related”