Preview, Logs and Problems

Preview

Preview shows the app at its own address, with its web/ files beside it; choosing a page file opens its route. Development's preview is the live dev server, so a saved file shows within seconds. Production's shows the deployed version, and is empty until the first deploy.

The phone button next to the address shows the app 400px wide, as on a phone. In that view, Code opens the page's file beside the phone; a component, stylesheet or other file chosen in the sidebar opens there too, and saving it (⌘S) updates the phone within seconds. Preview remembers the width and Code for each app and environment.

For a Shopify app, the preview opens admin pages as a chosen installed store, with a preview session in place of App Bridge's token, so routes that call verifyShopifySession work. Install the app on a store first.

For a web app, Preview as chooses who development's preview is signed in as: Unauthenticated, or any of development's user records (admins only). Choosing a user adds a session record for them, good for a day, and sets the app's own session cookie in the preview, so currentUser() finds them as it would after a sign-in. Signing in or out in the app itself works in the preview too. The preview's cookies stay in the preview: opening the app in a new tab starts signed out.

Logs

Every environment has an event log: syncs, webhooks, storefront requests, action runs, Shopify calls, builds, deploys and MCP calls. Logs lists them newest first for a time range, with a query bar, facets and one-click views, like the gateway's Logs. Open an event for its detail: what it was, who or what caused it, how long it took, and the events it caused (an action run lists the writes it made). Export downloads the matching events as CSV (up to 10,000 rows, with each event's actor, parent and detail).

Events are kept for the team's plan: 1 day on Free, 14 on Pro and 30 on Scale (webhook events at least 3). See Log retention.

Events record what happened, not payloads: a Shopify webhook keeps its topic, store, id and size, not its body. An action run keeps its params and log lines.

Event types

Common states are succeeded, failed, partial (an action whose onSuccess failed after its write), pending (a Shopify customers/data_request waiting for the team, with error = action_needed), rejected, conflict and unavailable (an app proxy request the app couldn't answer); builds and deploys also log started, running, ready, canceled and timed out. Sources are cli, dashboard, api, mcp, action, shopify, storefront and system.

Querying

The query bar takes field operator value conditions combined with AND, OR, NOT and parentheses, as on the gateway's Logs. Bare text matches event ids and names. Fields: type, name, status, state, error, source, duration, charge and id.

For example: type = action AND state = failed, status >= 400, type = webhook AND name ~ products, or duration > 2s. Views cover errors, syncs, webhooks, app proxy requests, action runs, background jobs (source = job), orphaned webhooks, Shopify calls, privacy requests (name ~ privacy), builds, deploys and model calls (charge > 0).

Failure emails

When production fails, the team's owners and admins, and the members whose access reaches the app, get an email naming what failed and why: each line is one kind of failure with how often it happened, when it last did, its error and a link to its newest event, with a button to Logs' errors. A failure is an event with a 5xx status, or a 4xx one that ended failed, timed out, canceled or partial: an action that threw or didn't answer, a deploy or build that failed, a configuration release Shopify refused, a storefront or extension route that answered 5xx, a model call or email that was refused. A background job counts once, when it gives up, never per attempt. Record writes a caller got wrong (rejected), 4xx answers the app chose to give, and anything in development are left out.

The first failure after a quiet spell is sent within a minute. Failures in the 12 hours after an email are held and sent together when the 12 hours are up, so every failure is in exactly one email and an app sends at most two a day. If nothing else failed in those 12 hours, nothing is sent, and the next failure goes out at once. To turn them off for an app, set alerts: { failures: false } in its settings.ib.ts; production's settings are its last deploy's.

Problems

The Problems panel lists what's wrong in the environment right now, grouped by file:

• TypeScript errors and warnings in web/, from a check the dev server runs after each sync. Each is replaced by the next check, so fixing a file clears its problems.
• The last Shopify release, when it failed (an error) or Shopify refused the storefront blocks (a warning), with a link to Settings → Shopify. A later release that goes through clears it.

The deploy plan has its own Problems in development: schemas that can't be read, a dev server that didn't start, and scopes that need Shopify's approval for production. Check this panel too before deploying: a TypeScript error here fails production's build.

Terminal

While ib-apps dev runs, the Terminal panel shows the computer and folder it runs in and the CLI's version, then each file it sends or receives. Until a computer connects, it shows the commands to run.

Ops

Ops charts the environment's requests by status, its errors, its action runs and the time spent, for the last hour, day, week or 30 days, with the top error codes, each action's runs with p50 and p95 times, and the slowest routes. Production's starts with the first deploy.