> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tappify.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Reporting and quality

> What owners report, what Tappify measures, and where you read both.

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

| Source            | Means                                                  |
| ----------------- | ------------------------------------------------------ |
| Tap Store         | The owner browsed and installed                        |
| A direct link     | An unlisted link                                       |
| A recipe          | A bundle Tappify suggested                             |
| The assistant     | The assistant recommended it in a conversation         |
| Connect Tappify   | An install started from your own product               |
| Your dev sessions | `tappify extension dev --live` on your sandbox project |

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

```json theme={null}
{ "telemetry": ["summary_viewed", "funnel_expanded"] }
```

```ts theme={null}
tap.telemetry.event("summary_viewed", { size: tap.ui.size });
```

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.