# Debugging a Deployed App

After every `gipity deploy`, verify the result - don't assume it worked. The deploy → **inspect** → fix loop is how you catch a blank page, a 500, or a broken asset before the user does. These commands are the inspect half.

## `gipity page-inspect <url>` - is the page healthy?

The first thing to run after a deploy. Loads the page in a real browser and reports what's wrong:

```bash
gipity page-inspect https://dev.gipity.ai/<account>/<project>/
```

Output:
- **Title, element count, page weight** - a near-empty element count means the page didn't render
- **Timing** - TTFB, DOM ready, load
- **Console** - every console message the page logged; JS errors show up here
- **Failed resources** - requests that 404'd or timed out (broken `src`/`href`, missing assets)

| Flag | Effect |
|---|---|
| `--all` | Also report render-blocking resources, files >100KB, oversized images, and LCP detail |
| `--wait <ms>` | Settle time after DOMContentLoaded before capturing (default 500) - raise it for late async work |
| `--no-truncate` | Show full URLs instead of middle-ellipsis |
| `--json` | Machine-readable output |

**Diagnosing a blank or broken page:** check **Console** for the JS error and **Failed resources** for anything that didn't load. A wrong asset path or an uncaught exception is almost always one of those two.

## `gipity page-screenshot <url>` - what does it actually look like?

Captures a PNG (saved as `ss-<host>-NNN.png` in the current directory):

```bash
gipity page-screenshot https://dev.gipity.ai/<account>/<project>/
gipity page-screenshot <url> --full                 # whole scrollable page
gipity page-screenshot <url> --device mobile,desktop # one load, multiple viewports
```

| Flag | Effect |
|---|---|
| `--full` | Capture the full scrollable page (default: viewport only) |
| `--device <names>` | Viewport presets: `default`, `desktop`, `laptop`, `tablet`, `mobile` (comma-separated) |
| `--viewport <WxH[@dpr]>` | Raw viewport, e.g. `414x896@2` |
| `-o <file>` | Output filename (single viewport only) |
| `--post-load-delay <ms>` | Delay after load before capture (default 1000) |
| `--json` | Output metadata (page title, status, performance) instead of a summary |

Use `--device mobile,tablet,desktop` to check responsive layout in one shot.

## `gipity logs fn <name>` - why did a function fail?

When a function returns a 500 or wrong data, read its execution logs:

```bash
gipity logs fn get-weather            # recent runs
gipity logs fn get-weather --limit 50
```

Each entry shows time, status (`success` / `error`), duration, trigger type, and the **error message** for failed runs. `gipity fn logs <name>` is the equivalent under the `fn` command group.

## `gipity fn call <name> [body]` - test a function directly

Invoke a deployed function from the CLI, bypassing the frontend - the fastest way to confirm a fix:

```bash
gipity fn call get-weather '{"zip": "90210"}'
gipity fn call get-weather --data '{"zip": "90210"}'
```

It prints the function's JSON response. `gipity fn list` shows every deployed function with its version and auth level.

## A debugging pass

1. `gipity page-inspect <url>` - console clean? resources all loading?
2. Console shows a JS error → fix the frontend code, redeploy.
3. A `fetch` to your own function failing → `gipity logs fn <name>` for the server-side error.
4. Reproduce and confirm the function fix with `gipity fn call`.
5. `gipity page-screenshot --device mobile,desktop` - looks right everywhere?

## Related skills

- [deploy](deploy.md) - the deploy step that precedes every inspect
- [app-development](app-development.md) - writing and testing the functions you're debugging
- [web-app-basics](web-app-basics.md) - frontend patterns and common page bugs