Skip to main content
The Runtime page in the developer portal is where an extension’s behaviour in the field shows up: who installed it, what synced, what owners approved, what failed to load, what owners reported, and what ran. Four tiles lead it — installs all time, the load failures you have been sent, install tokens minted in the last thirty days, and widget views in the last thirty days.

Installs, by where they came from

The source is recorded when the install is created and never changed, so attribution stays honest. The breakdown covers the last thirty days; the total above it is every install since you published.

Load failures

When your remote fails to load, the host draws a card with Retry and Report to vendor. An owner who presses Report sends the error, the stack, the page, your release checksum and the host version — no owner data. Reports land on your Runtime page, newest first, and the previous day’s are summed into a digest email to your vendor admins each morning with a count and the error you saw most. The reason is on the card. A bundle that exceeds the 8-second remote entry timeout reads remoteEntry.js timed out after 8s; anything else is the error your code threw as the host mounted it.

Owner reports

An owner can report your extension from the install’s page with a note. A Tappify admin reads it, and you are told: the note, and whether it is open, reviewed or dismissed, appears on your Runtime page, and a notice reaches your vendor admins. A suspended extension stops loading in every host on its next install refresh, about a minute, and shows a card reading Starter is temporarily unavailable. The rest of Tappify is unaffected.

Telemetry you declare

At most 20 snake_case names, flat properties, 60 events per minute per install. A name that is not on the live release’s list is refused rather than stored, so declare it and ship a release before you send it. The Runtime page’s event table counts the last thirty days by event type, which puts every telemetry event on one row; the per-name breakdown arrives with the metrics below. The owner’s own install page lists that install’s recent runtime events.

Sync health

Every install running your connector, rolled into one line: installs syncing, the newest sync that succeeded, rows in the last 24 hours, and the slowest install’s p95. Under it, the count of installs that could not reach your server on their last sync — the number to act on. An install that has never once succeeded still appears there, so a connector that only ever fails is not reported as “nothing has synced yet”.

Actions

The share of the actions you asked owners to approve in the last thirty days that they approved, with the two counts behind it. Under 60% flags your listing, so the sentence beside it says so.

Event replay

The last fifty deliveries across every install, each with the outcome the host recorded — alert raised, banner shown, recorded, duplicate, rate limited or rejected. Replaying runs the stored delivery’s outcome again; it does not create a second delivery, and a replayed alert still counts against that project’s three alerts a day.

Store funnel

Listing views in the last thirty days, installs added in that window that are still installed, and the installs older than thirty days that are still installed. The third number is a count, not a share of the second.

The public quality panel

Tappify computes four numbers over the last 90 days and shows them on your listing: server uptime, assistant tool response time at the 95th percentile, the share of your actions owners approve, and the number of installs kept after 30 days. A number Tappify has not measured yet says so rather than showing a zero. An extension below any threshold — uptime under 99.5%, tool response over 4 seconds, approvals under 60% — is flagged on its Tap Store card and on its listing, with a line per reason naming the number that failed.

What is still coming

One section of the Runtime page says so rather than showing a number: tool calls and response times arrive with assistant tools.