Verify your first event
Once your application is configured with the SDK, run it and trigger any tracked event. This page walks you through confirming the event arrived in Beacon — or diagnosing why it didn’t.
Two different latencies
Beacon shows your data through two different layers, and they update on different schedules. Knowing which is which avoids the most common false alarm during integration testing — “I sent an event, why isn’t it showing up?”
- Aggregated data powers most pages — Overview, Event Explorer, Property Explorer, Sessions, Retention, Usage Insights, Anomalies, and most reports. Beacon refreshes these every 15 minutes, so a freshly-ingested event can take up to 15 minutes to appear.
- Live data powers Funnels, Actor Identities, and the Invalid Events page. These reflect ingestion within seconds of the SDK flushing.
The fastest place to see “did my event ingest?” is the Invalid Events page (under Data) — if your event is rejected, it’ll appear there within seconds, with the reason. If it’s accepted, it won’t show up there at all, and you’ll see it in Event Explorer after the next 15-minute refresh.
What to expect
The SDK batches events on a timer — every 60 seconds for .NET / C++, every 10 seconds for JavaScript. A single test event may take up to that long to flush. To force a flush sooner, call FlushAsync() / flush() from your application.
Step 1 — Trigger an event
Run your application and perform whatever action your SDK code is tracking — sign in, click a button, navigate to a page. The SDK handles batching automatically; you don’t need to do anything special to “send.”
If you’re testing from a development environment, identify the user with a clearly fake actor ID (for example, test-user-1) so you can find and clean up your test data later.
Step 2 — Check Invalid Events
In the sidebar, expand Data and click Invalid Events. This is the fastest source of truth — events appear here within seconds if the API rejected them.
If your event is on this page, the SDK is reaching the API but the payload was rejected. The most common reasons:
UNRECOGNIZED_PRODUCT— the SDK’ssource_appdoesn’t match a product slug you created. Re-check that the slug matches exactly (it’s case-sensitive). A common mistake is"InventoryManager"vs the actual slug"inventory-manager".PAYLOAD_TOO_LARGE— your event has a property value or stack trace exceeding the per-event limit. Trim the data.- HTTP 429 (rate limited) — your application is sending too fast. Tune the SDK’s batch size and flush interval.
If your event is not on this page, the SDK either reached the API and was accepted (good — proceed to Step 3) or never reached the API (proceed to Step 4).
Step 3 — Watch Event Explorer
In the sidebar, expand Explore and click Event Explorer. Because this page reads aggregated data, your event won’t appear until the next refresh — up to 15 minutes after ingestion.
If your test included a call to Identify with a fake actor ID, you can also check Actor Identities — that page reads live data and reflects new identified actors within seconds. The presence of your test actor confirms ingestion. (If you didn’t call Identify, this check doesn’t apply — the absence of an actor doesn’t mean the event failed.)
If you see your event in Event Explorer (or your test actor in Actor Identities, when applicable), the SDK is correctly configured. Proceed to Invite a teammate.
Step 4 — If nothing appears within 15 minutes
If neither Event Explorer nor Invalid Events nor Actor Identities shows any sign of your event, the SDK isn’t reaching the API. Check, in order:
Check the SDK’s last flush status
All three SDKs expose the result of the last batch send (LastFlushStatus in .NET, last_flush_status() in C++, debug-mode console output in JavaScript). If the last flush errored, the message tells you why — often a 401 (wrong API key), a 402 (plan event limit reached), or a network error.
Check your network
The SDK sends to https://api.beacon.softagility.com. If your application runs behind a corporate proxy or firewall, that hostname needs to be on the outbound-allowed list. Beacon only needs outbound TLS — no inbound traffic.
Enable the SDK logger
Both .NET and C++ SDKs accept an optional logger; the JS SDK has a debug: true config option. Enable it temporarily — every batch send logs success or failure with the HTTP status code. This is the fastest way to diagnose what the SDK is actually doing.