Monitor

Monitoring

Add your app once and PatchLabs re-checks it on a schedule, shows you what changed since last time, and tells your team when a new leak appears.

Add an app

1. Sign in with your email. We send a magic link; there are no passwords. Your first sign-in creates a personal workspace, and any free checks you ran with that email appear in your dashboard.
2. Press Add app and enter the repo. Optionally add a client label and choose a schedule.
3. Commit the verification file with the app’s code and press verify. The app is verified for good and its first check is queued straight away.

The same with the API (get your workspace ID from GET /me):

curl -s -X POST https://api.patchlabs.dev/workspaces/$WORKSPACE_ID/apps \
  -H "Authorization: Bearer $PL_SESSION" -H 'Content-Type: application/json' \
  -d '{"repo": "you/your-app", "client_label": "Acme", "schedule": "monthly"}'
# 201 → {"id": "…", "verified": false, "verify": {"file": "patchlabs-verify.txt", "code": "patchlabs-…", "add_url": "…"}, …}

curl -s -X POST https://api.patchlabs.dev/apps/$APP_ID/verify -H "Authorization: Bearer $PL_SESSION"

Each repo can be added to a workspace once. Adding more apps than your plan allows answers 403 with the limit in plain words.

Schedules

• The clock starts when the app is verified. Changing the schedule restarts it from that moment.
• A scheduled check is skipped while another check for the app is still queued or running, and picked up on the next pass.
• Scheduled checks don’t count towards your monthly run limit. They keep running even when you’ve used all your manual runs.
• Every check reads the repo’s default branch as it is on GitHub at that moment.

curl -s -X PATCH https://api.patchlabs.dev/apps/$APP_ID \
  -H "Authorization: Bearer $PL_SESSION" -H 'Content-Type: application/json' \
  -d '{"schedule": "weekly"}'

Run now

Press Run now in the apps list or Run check now on the app’s page, or call the API. It’s the quickest way to confirm a fix you’ve just shipped.

curl -s -X POST https://api.patchlabs.dev/apps/$APP_ID/checks -H "Authorization: Bearer $PL_SESSION"
# 201 → {"check_id": "…", "status": "queued", "url": "https://patchlabs.dev/check?id=…"}

• 409 if a check for this app is already queued or running. Wait for it to finish.
• 429 once the workspace has used its manual runs for the month. Runs from the dashboard, the API, CI and the MCP server share the same allowance, which resets on the 1st of each month.

What changed since last time

Each app compares its last two finished checks and sorts the leaking tables into four lists:

new_leaks

Leaking now, not leaking last time. These trigger the “New leak found” email.

fixed

Leaking last time, not now.

still_leaking

Leaking both times.

suppressed

Leaking, but your team marked it as intended. No alert.

"diff": {
  "new_leaks": ["orders"],
  "fixed": ["profiles"],
  "still_leaking": [],
  "suppressed": ["shops"],
  "to_check_id": "…", "from_check_id": "…"
}

Check history

The app’s page lists its latest 50 checks, newest first, with how each one started (its trigger), when it finished, which tables leaked and whether the lab proof passed.

Notifications

When an app’s check finishes, every member of the workspace gets an email, and the workspace webhook (if set) gets a POST.

• The subject reads “New leak found in your-app (Acme)” when there is anything in new_leaks, and “PatchLabs check finished for …” otherwise.
• The email lists new leaks, fixed tables, tables still leaking and tables marked as intended, with links to the report and the app.
• If a check couldn’t finish, members aren’t emailed (we are, and we follow up); the webhook still receives it with status failed.

Set up Slack, Discord or your own endpoint on the webhooks page.

Plan limits

API keys, webhooks, badges and client labels are on every plan. See pricing. Card payments aren’t live yet: request an upgrade from your settings and we reply within a day.