Checking Your Events

The quickest way to check that events are arriving is the source’s Debugger tab in the Silo console. Every time it refreshes (every 5 seconds) it first fetches anything still on its way, so a page view should show up within seconds of the page loading.

Without console access

If you can’t get into the console, your browser’s dev tools will tell you most of it. Open the Network tab and reload the page.

1. Look for the request to cdn.silo.adpharm.digital/v1/projects/<your write key>/settings. It should come back 200. A 404 means the write key is wrong.
2. Each event is a request to event-gateway.silo.adpharm.digital. A 200 reply means Silo took it, unless the reply says "blocked": "localhost" (see below).

Once you see accepted events, ask your Silo contact to check the debugger for you.

Not in the analyst MCPs yet

Silo saves events in batches about every 30 minutes, so tools that read the stored data directly, like the Silo analyst MCPs, can be up to half an hour behind. If an event is in the debugger but not there yet, it isn’t lost. Give it time.

The Read API fetches waiting events before it answers, so it’s normally current.

Not showing up at all

• You’re testing from localhost. The gateway drops localhost events unless debug is on. Pass debug: true to load() while you test, and take it out before you ship. See silo.debug.
• The visitor didn’t consent. Silo sends nothing for a capability the visitor hasn’t allowed. See Consent.
• It’s the first page view of a fresh visit. On sites with device-mode destinations, a page view fired before the library finishes loading can be dropped. See The initial page view.

Seeing an event twice

A retried send never becomes a second row: Silo stores each messageId once. Several Time on Page rows for one page view are separate beacons, not duplicates. See Server-Side Deduplication.