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:
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):
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:
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:
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
gipity page-inspect <url>- console clean? resources all loading?- Console shows a JS error → fix the frontend code, redeploy.
- A
fetchto your own function failing →gipity logs fn <name>for the server-side error. - Reproduce and confirm the function fix with
gipity fn call. gipity page-screenshot --device mobile,desktop- looks right everywhere?
Related skills
- deploy - the deploy step that precedes every inspect
- app-development - writing and testing the functions you're debugging
- web-app-basics - frontend patterns and common page bugs