api-health

작성자: facebook

Meta 앱의 API 상태를 모니터링합니다 — 비율 제한, 호출량, API 지원 중단 여부를 확인합니다. 트래픽 제한을 진단하거나, 용량을 계획하거나, API 버전 변경에 대비하는 데 사용합니다…

npx skills add https://github.com/facebook/agentic-tools --skill api-health

API Health

Monitor API usage, rate limits, and deprecations for a Meta app.

Workflow

  1. Start tracking. Before any other work, call devtools_skill_invocation with action start and skill_name api-health. Pass skill_name api-health on every devtools_* tool call in the following steps.

  2. Identify the app. Ask the user for the app name or ID. If they give a name (or aren't sure of the ID), call devtools_app_list (action list) and resolve it to an app_id — match the name case-insensitively. If several apps match or it's ambiguous, show the candidates (name, ID, viewer role) and ask the user to pick. If they give a numeric ID, use it directly.

  3. Collect API health data in parallel:

    • devtools_api_usage with action rate_limits — current rate limit status per metric
    • devtools_api_usage with action call_volume — total calls vs quota
    • devtools_api_usage with action deprecations — deprecated APIs and migration guides
  4. Analyze and report:

    Report Format

    Rate Limits

    • Report the overall_status the response already carries — healthy, warning, critical, throttled, or unmetered. Do not re-derive it from the percentage; the server classifies on an unrounded value, so a borderline case can read critical while usage_percentage displays 100.
    • usage_percentage for the call_count_usage_rate metric (0–100, rounded for display)
    • Effective users count (DAU/WAU/MAU aggregate) — the denominator the quota is multiplied by
    • cooling_down_minutes: estimated minutes until unblock, 0 when not over quota
    • On unmetered, say the app is not metered rather than reporting 0% — it means no usable headroom reading, not spare capacity

    Call Volume

    • Total calls and quota
    • Usage rate (calls/quota ratio, 0.0–1.0)
    • Interpret it on the same bands the platform uses for rate limits: >= 0.7 approaching, >= 0.9 critical, 1.0 means the app is at its quota
    • If the user provided an endpoint filter, show filtered results

    API Deprecations

    • Latest platform version
    • Each deprecation with: type, name, severity, and recommendation
    • Link to migration guides where available

    Action Items

    • Prioritized by severity:
      1. Throttled rate limits (immediate action needed)
      2. Critical rate limits (at or above 90% — throttling is imminent)
      3. High-severity deprecations (migration required)
      4. Warning-level rate limits (monitor or optimize)
      5. Low-severity deprecations (plan for future)
  5. Offer deeper investigation based on findings:

    • If throttled: offer to check call volume for specific endpoints (endpoint param) to find the hot path
    • If deprecations found: offer to search docs (/search-docs) for migration guides
    • If healthy: suggest setting up a monitoring cadence
  6. End tracking. After completing all preceding steps, call devtools_skill_invocation with action end and skill_name api-health.

Advanced Usage

Check specific endpoint volume

If the user wants to investigate a specific API endpoint, call devtools_api_usage with action call_volume and pass the endpoint parameter (e.g., /me/feed) to filter results to that path.

Custom lookback window

The lookback_minutes parameter controls the time range (default: 1440 = 1 day):

  • Last hour: lookback_minutes = 60
  • Last week: lookback_minutes = 10080
  • Last 30 days: lookback_minutes = 43200

Tips

  • Rate-limit bands: healthy < 70%, warning >= 70%, critical >= 90%, throttled at 100%. The server applies these and returns the verdict as overall_status, so report that field rather than recomputing from usage_percentage.
  • usage_rate in call_volume is a share of quota capped at 1.0 — 1.0 means the app is at its quota, and no value above it is reachable.
  • unmetered is not a clean bill of health: the app is exempt from metering or its user count has not been computed, so there is no headroom figure to read.
  • Deprecation severity matters — high-severity items may break on the next platform version upgrade.
  • Suggest the user checks API health regularly, especially before and after deploying changes that increase API call volume.

facebook의 다른 스킬

gc-safe-coding
facebook
전체 설명과 근거는 doc/GCSafeCoding.md를 참조하십시오.
app-review-prep
facebook
Meta 앱을 App Review용으로 준비합니다 — 현재 상태, 미해결 요구 사항, 부여된 권한, 제출 내역을 확인합니다. 앱을 제출하기 전에 사용하세요…
debug-webhooks
facebook
Meta 앱의 웹훅 문제를 해결합니다 — 활성 구독을 검사하고, 잘못된 구성을 식별하며, 테스트 페이로드를 전송하여 전달을 확인합니다. 다음과 같은 경우에 사용하세요…
api-integration
facebook
개발자가 Meta API 통합을 처음부터 설정하도록 안내합니다 — 적절한 API를 찾아내고, 설정 가이드, 인증 요구 사항 등을 가져옵니다…
webhook-setup
facebook
Meta 앱용 웹훅을 처음부터 끝까지 설정하세요 — 사용 가능한 주제를 탐색하고, 필드를 구독하고, 테스트 페이로드로 검증합니다. 웹훅을 구성할 때 사용하세요…
test-ui
facebook
iwsdk CLI를 사용하여 포크 예제에 대해 Test UI 시스템(PanelUI, ScreenSpace)을 테스트합니다.
flags
facebook
React 릴리스 채널 간 기능 플래그 상태를 검사하고 비교합니다. 모든 채널(www, www-modern, canary, next, experimental, rn 변형)의 플래그를 보거나 --diff로 특정 채널을 비교합니다. 출력 형식은 기본 테이블 보기, CSV 내보내기, 정리 상태 그룹화를 포함합니다. 플래그 상태는 기호로 표시됩니다: 활성화(✅), 비활성화(❌), 변형 테스트(🧪), 프로파일링 전용(📊). 일반적인 실수: __VARIANT__ 플래그는 www에서 두 상태 모두 테스트되며, --diff를 사용하여 의미 있는 차이를 찾습니다...
compliance-check
facebook
Meta 앱의 컴플라이언스 상태를 확인합니다 — 미해결 필수 조치, 활성 위반 사항, 권장 사항 및 수정 지침을 표시합니다. 감사에 사용하세요…