Griffin API & Browser Monitors

This skill teaches you how to create effective monitors with Griffin: scheduled checks that run HTTP requests against endpoints and/or launch real browsers to interact with web pages, then assert on responses and page state. Monitors are defined in TypeScript using @griffin-app/griffin and live in __griffin__ directories. The goal is to add monitors that provide value—catching real failures and reflecting real business behavior—not just "200 OK" checks.

1. When to use this skill

• User asks to add, create, or design API monitors, browser monitors, or health checks.
• User wants to evaluate which endpoints or UI flows in their codebase should be monitored.
• User is writing or editing monitor files in __griffin__ and needs correct DSL usage and assertion patterns.
• User mentions Griffin monitors, scheduled API tests, browser tests, or endpoint/UI monitoring in the context of this project.

2. Evaluating what to monitor

API monitors

Prioritize user-facing or critical path (login, checkout, core reads/writes), dependencies other services rely on, and contract endpoints (public/partner APIs). Assert on behavior, not only status: status plus key body fields, headers, and (when relevant) latency. Match business logic (e.g. list shape data.items[] with id, name). Use high frequency (e.g. 1 min) for critical health/auth, lower (5–15 min) elsewhere.