Agent skill · software engineering · jeremylongshore
procore-observability
Monitor Procore Integration Health, API activity, rate budget, webhook deliveries, and synchronization freshness with route-level ownership. Use when defining dashboards, alerts, service objectives, or a regular health-review cadence. Trigger with: "monitor Procore integration", "review Procore API activity", "alert on Procore health".
Why this skill is useful
Provides specific API integration patterns and error handling for Procore that the AI wouldn't reliably generate on its own.
What it needs
Requires requests installed locally. Requires procore account access. About 2k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.
What this skill does
Procore Integration Health Observability Overview Combine provider-side observations with application-side service signals. Procore's Integration Health and API Call Activity Report identify unhealthy response patterns and routes, while the integration must supply latency, backlog, freshness, reconciliation, and release context. Prerequisites App owner with Developer Portal access and a recurring review cadence Normalized route, status, latency, retry, queue, webhook, and freshness telemetry Release identifiers, endpoint owners, alert destinations, and incident runbook Instructions Step 1: Export provider evidence Review Integration Health and download the production API activity report. Preserve report time range, app identity, and a checksum in the audit receipt. Step 2: Join route ownership Map normalized route, method, status, and count to the responsible service and adapter. Flag unknown traffic as a legacy deployment or credential-compromise hypothesis. Step 3: Monitor provider limits Track rate limit, remaining budget, reset time, Retry-After, 401, 403, 404, 422, 429, and 5xx outcomes by route and release. Step 4: Monitor data freshness Track webhook acknowledgment and delivery outcomes, queue age, deduplication, reconciliation cursor age, changed records, and parity failures. Step 5: Define actionable alerts Every alert names the affected tenant boundary, route owner, runbook, severity, and recovery condition. Exclude tokens, payloads, names, and signed URLs. Step 6: Close the loop After remediation, verify application metrics and the provider observation history. Record when provider-side status may lag the underlying fix. Authentication Provider evidence is accessed through authorized Developer Portal sessions, while API probes use the intended OAuth 2.0 principal. Observability stores aliases and normalized metadata, never tokens or raw construction payloads. Tool Discipline Use Read and Grep to inspect reports, telemetry, releases, and runbooks. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills jeremylongshore/procore-observability--c509f5