# GitHub Repo Health Check (MCP Server) (`joeslade/github-repo-intelligence-mcp`) Actor Opinionated health verdicts for any GitHub repo—Actively maintained, Slowing, At-risk, or Likely abandoned—exposed as 5 MCP tools, with the raw metrics behind every verdict so your agent can see the why. - **URL**: https://apify.com/joeslade/github-repo-intelligence-mcp.md - **Developed by:** [Joe Slade](https://apify.com/joeslade) (community) - **Categories:** AI, MCP servers, Developer tools - **Stats:** 1 total users, 0 monthly users, 0.0% runs succeeded, 1 bookmarks - **User rating**: No ratings yet ## Pricing Pay per usage This Actor is paid per platform usage. The Actor is free to use, and you only pay for the Apify platform usage, which gets cheaper the higher subscription plan you have. Learn more: https://docs.apify.com/platform/actors/running/actors-in-store#pay-per-usage ## What's an Apify Actor? Actors are a software tools running on the Apify platform, for all kinds of web data extraction and automation use cases. In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours, and optionally produces a well-defined JSON output, datasets with results, or files in key-value store. In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server. Actors are written with capital "A". ## How to integrate an Actor? If asked about integration, you help developers integrate Actors into their projects. You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready. The best way to integrate Actors is as follows. In JavaScript/TypeScript projects, use official [JavaScript/TypeScript client](https://docs.apify.com/api/client/js.md): ```bash npm install apify-client ``` In Python projects, use official [Python client library](https://docs.apify.com/api/client/python.md): ```bash pip install apify-client ``` In shell scripts, use [Apify CLI](https://docs.apify.com/cli/docs.md): ````bash # MacOS / Linux curl -fsSL https://apify.com/install-cli.sh | bash # Windows irm https://apify.com/install-cli.ps1 | iex ```bash In AI frameworks, you might use the [Apify MCP server](https://docs.apify.com/platform/integrations/mcp.md). If your project is in a different language, use the [REST API](https://docs.apify.com/api/v2.md). For usage examples, see the [API](#api) section below. For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt). # README **GitHub Repo Intelligence** is an MCP server that answers the question "is this GitHub repository still actively maintained?" — returning one of four verdict labels (*Actively maintained*, *Slowing*, *At-risk*, *Likely abandoned*) backed by the transparent, inspectable metrics that produced it. Point it at any `owner/name` (or GitHub URL) and your agent gets a verdict it can act on, plus the raw numbers so it can see exactly why. It runs as a [Standby Actor](https://docs.apify.com/platform/actors/development/programming-interface/standby) on the [Apify platform](https://docs.apify.com/platform) — always warm, reachable over the [Streamable HTTP transport](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#streamable-http) at the `/mcp` path, with API access, scheduling, and monitoring included. ### Who is this for? - **Agent developers** whose agents need to decide whether to adopt, recommend, or monitor an open-source library or tool - **Dependency due-diligence** — vetting whether a package's upstream is alive before committing to it - **OSS vendor evaluation** — checking the health of a project before building on it - **Repo triage at scale** — ranking a list of candidates by health before a human reviews them - **Automated monitoring** — scheduling recurring checks and alerting when a dependency starts slowing If you've ever asked "is this repo abandoned?" or run a GitHub repo health check by hand, this server does it programmatically at any scale. ### Why use GitHub Repo Intelligence? Most GitHub tools hand an agent raw API access and leave the judgment to the model — inconsistent, hand-rolled heuristics on every call. This server does the synthesis for you. The differentiator is **judgment, not raw access**: every verdict ships alongside the pinned thresholds and raw metrics that produced it, so the agent (and you) can audit the reasoning. Same repo state + same config always yields the same verdict. One GitHub fetch per repository is cached and shared across all five tools. Drilling from the headline verdict into a specific dimension costs no extra upstream calls. ### How to use GitHub Repo Intelligence 1. **Deploy the Actor** — run it in Standby mode on Apify. It boots with no input required. 2. **Connect your MCP client** to the Standby endpoint (`https:///mcp`) using the Streamable HTTP transport. 3. **Call `get_repo_health`** with a `repo` argument (`"owner/name"` or any `https://github.com/owner/name` URL) to get the headline verdict. 4. **Add a GitHub token** — this is effectively required. The Actor's primary data source (GitHub's GraphQL API) rejects unauthenticated requests, and Apify's shared egress IPs exhaust GitHub's anonymous quota almost immediately. Without a token the Actor returns rate-limit errors, not verdicts. See [Input](#input) for setup. 5. **Drill into dimensions** — call `get_activity_metrics`, `get_issue_health`, `get_pr_health`, or `get_contributor_insights` when you need detail beyond the headline. All five tools read from the same cached payload. ### The five tools All tools take a single `repo` argument — either `"owner/name"` or any `https://github.com/owner/name[/...]` URL (case-insensitive). #### `get_repo_health` — headline verdict Returns the overall verdict, a per-dimension breakdown, and a rationale string explaining the worst dimension. ```jsonc { "repo": "honojs/hono", "overallVerdict": "Actively maintained", "dimensions": { "activity": { "verdict": "Healthy", "lastCommitDaysAgo": 1, "commits90d": 412 }, "issues": { "verdict": "Healthy", "medianFirstResponseDays": 2.4, "staleOpenRatio": 0.12 }, "pullRequests": { "verdict": "Healthy", "mergeRate": 0.88, "oldestOpenPrDaysAgo": 14 }, "contributors": { "verdict": "Healthy", "totalContributors": 312, "busFactorFlag": false } }, "rationale": "Overall: activity is Healthy; weakest dimension is issues (Healthy).", "stars": 21000, "forks": 640, "fetchedAt": "2026-06-01T00:00:00.000Z", "authenticated": true } ```` #### `get_activity_metrics` — commit cadence and momentum Commit volumes over trailing windows, release frequency, and a momentum trend. ```jsonc { "repo": "honojs/hono", "verdict": "Healthy", "lastCommitDaysAgo": 1, "commits30d": 140, "commits90d": 412, "commits365d": 1680, "releaseCount365d": 48, "lastReleaseDaysAgo": 3, "momentumTrend": "steady", "fetchedAt": "2026-06-01T00:00:00.000Z" } ``` `momentumTrend` is `accelerating` / `steady` / `declining`, derived from the 30-day commit rate vs the 90-day rate. Repos that tag rather than cutting GitHub Releases will show `releaseCount365d: 0` and `lastReleaseDaysAgo: null` — this does not by itself degrade the verdict. #### `get_issue_health` — responsiveness and backlog hygiene How quickly maintainers respond to issues and how much of the backlog has gone stale. ```jsonc { "repo": "honojs/hono", "verdict": "Healthy", "openIssues": 32, "closedIssues": 1840, "openClosedRatio": 0.017, "medianFirstResponseDays": 2.4, "medianTimeToCloseDays": 5.1, "staleOpenIssues": 4, "staleOpenRatio": 0.12, "fetchedAt": "2026-06-01T00:00:00.000Z" } ``` An issue is **stale** if untouched for more than 90 days. Medians are `null` when no qualifying events exist in the analysis window — absence is not the same as zero. #### `get_pr_health` — PR throughput and queue age How effectively the project merges or closes contributions, and how old the oldest open PR is. ```jsonc { "repo": "honojs/hono", "verdict": "Healthy", "openPrs": 6, "mergedPrs": 220, "closedUnmergedPrs": 30, "mergeRate": 0.88, "medianTimeToMergeDays": 1.2, "oldestOpenPrDaysAgo": 14, "fetchedAt": "2026-06-01T00:00:00.000Z" } ``` `mergeRate` excludes still-open PRs from the denominator. It is `null` when no PRs have been decided in the analysis window. #### `get_contributor_insights` — concentration and bus-factor risk How many contributors the project has and whether commit activity is dangerously concentrated. ```jsonc { "repo": "honojs/hono", "verdict": "Healthy", "totalContributors": 312, "topContributorShare": 0.28, "topTwoContributorShare": 0.41, "busFactorFlag": false, "fetchedAt": "2026-06-01T00:00:00.000Z" } ``` `busFactorFlag` is `true` when the top contributor owns more than 50% of commits, or the top two together own more than 80%. `totalContributors` is the repository's **all-time** contributor count (sourced from GitHub's stable `/contributors` list endpoint) — it is not a 90-day-active count. ### Verdict thresholds Verdicts come from pinned, transparent thresholds — same repo state plus same config always yields the same verdict. | Dimension | `Healthy` | `Moderate` | `At-Risk` | Notes | |---|---|---|---|---| | **Activity** | last commit ≤ 30d | 30–180d | 180–365d | `Likely abandoned` if > 365d | | **Issues** | median first response ≤ 7d **and** staleOpenRatio ≤ 0.40 | ≤ 30d **and** ≤ 0.60 | otherwise | null median → judged on staleOpenRatio alone | | **Pull requests** | mergeRate ≥ 0.60 **and** oldestOpenPr ≤ 30d | mergeRate ≥ 0.30 **or** oldestOpenPr ≤ 90d | otherwise | null mergeRate → judged on oldestOpenPr alone | | **Contributors** | totalContributors ≥ 3 **and** not bus-factor | 1–2 contributors, or ≥ 3 with bus-factor | 0 contributors | solo active maintainer → at most `Moderate` | **Overall verdict** is activity-dominant, evaluated top-down (first match wins): 1. **Likely abandoned** — activity is `Likely abandoned` (no commits in > 365 days). 2. **At-risk** — activity is `At-Risk`, or any two of {issues, PRs, contributors} are `At-Risk`. 3. **Actively maintained** — activity is `Healthy` and no dimension is `At-Risk`. 4. **Slowing** — everything else (e.g. activity `Moderate`, or `Healthy` activity with one `At-Risk` dimension). ### Input The server boots with **no input required** (a Standby constraint — all fields are optional in the schema so the container never crash-loops on startup). In practice, you must provide a GitHub token for the Actor to return verdicts rather than rate-limit errors. | Field | Type | Default | Description | |---|---|---|---| | `githubToken` | string (secret) | — | **Effectively required.** GitHub's GraphQL API (this Actor's primary data source) rejects unauthenticated requests, and on Apify's shared IPs the anonymous REST quota (~60 req/hour per IP) is typically already exhausted by other traffic. A token gives 5,000 req/hour and enables private-repo analysis. | | `cacheTtlMinutes` | integer | `20` | How long a repo's fetched payload is reused before refetching. Lower = fresher data; higher = fewer GitHub API calls. | | `analysisWindowDays` | integer | `90` | Trailing window (30–365 days) over which issue and PR activity is measured. | > **GitHub token setup.** A classic token with no scopes is sufficient for public repositories. A fine-grained token scoped to specific repos works for private-repo analysis. For Standby deployments the recommended approach is to set a `GITHUB_TOKEN` environment variable on the Actor (stored as a secret) rather than pasting the token into the input field — it persists across restarts. Both paths work; both are stored as secrets and never exposed in logs. ### Output Each tool returns a single structured JSON object (shown above in each tool's section). Responses are deterministic — same repo state plus same config always produces the same verdict. Each response includes a `fetchedAt` timestamp reflecting when the underlying GitHub payload was pulled. A cached read returns the same timestamp as the original fetch for that TTL window. ### Data fields reference | Field | What it tells you | |---|---| | `overallVerdict` | The headline: Actively maintained / Slowing / At-risk / Likely abandoned | | `lastCommitDaysAgo` | Days since the most recent commit; `null` if no commits found | | `commits30d` / `commits90d` / `commits365d` | Commit counts over trailing 30, 90, and 365-day windows | | `momentumTrend` | Whether commit rate is accelerating, steady, or declining (30d vs 90d rate) | | `medianFirstResponseDays` | Median time (days) until a maintainer first responds to a new issue | | `staleOpenRatio` | Fraction of open issues that have had no activity in 90+ days | | `mergeRate` | Merged PRs ÷ (merged + closed-unmerged) — excludes still-open PRs | | `oldestOpenPrDaysAgo` | Age of the oldest PR that is still open | | `totalContributors` | All-time contributor count (not a 90-day-active figure — see FAQ) | | `busFactorFlag` | `true` when commit activity is dangerously concentrated on 1–2 people | ### Pricing This Actor runs in Standby mode and is billed for the compute used while warm and serving requests. Health reads are lightweight — each repo's GitHub data is fetched once, cached (default 20 minutes), and shared across all five tools. Drilling into multiple dimensions for the same repo costs a single upstream fetch. A GitHub token is required in practice (see [Input](#input)) and adds no extra Apify cost. ### Tips - **Start with `get_repo_health`** for the headline verdict, then call a dimension tool only when you need detail — they all share the same cached payload. - **Raise `cacheTtlMinutes`** when triaging a long list of repos in a batch to minimize GitHub API calls. Lower it when you need fresh reads. - **Set `GITHUB_TOKEN` as an environment variable** on the Actor rather than in the input field — it persists across Standby restarts without re-supplying input. - **Adjust `analysisWindowDays`** (30–365) to match how recent you need issue and PR signals to be. A shorter window surfaces recent trajectory; a longer window averages over a steadier baseline. ### How it works 1. An MCP client sends a tool call (e.g. `get_repo_health`) with a `repo` argument. 2. The server checks an in-memory LRU cache. On a miss, it fires a single GraphQL query to GitHub's API (plus a REST call for contributor data) and caches the raw payload. 3. Pure metric-computation functions derive counts, medians, and ratios from the payload — no further network calls. 4. Verdict functions compare each metric against the pinned thresholds in `config.ts` and return a dimension verdict. 5. The overall verdict is composed from the four dimension verdicts using the activity-dominant rule above. 6. The full result — verdict, per-dimension breakdown, raw metrics, and `fetchedAt` — is returned to the MCP client. All five tools share step 2's cached payload. The verdict logic is deterministic and clock-injected (testable without network). ### Works well with Part of a small slate of agent-focused Apify Actors: - **[SERP Topic Gap Monitor](https://apify.com/joeslade/serp-topic-gap-monitor)** — finds topic gaps in search-result coverage and produces scored gap reports. - **[Changelog Triage Agent](https://apify.com/joeslade/changelog-triage-agent)** — monitors product changelogs across services, classifies each new entry as BREAKING / WARNING / INFO, and delivers a de-duplicated triage report so teams catch deprecations before they bite. - **[Docs MCP Server](https://apify.com/joeslade/docs-mcp-server-starter)** — an MCP server giving AI assistants queryable access to framework documentation (Next.js, React, Tailwind, TypeScript, Prisma). ### FAQ and support **Does it work on private repositories?** Yes — provide a `githubToken` with read access to the repo. **Is the verdict subjective or configurable?** No. Every verdict comes from the pinned thresholds documented above. Same repo state always yields the same verdict. The raw metrics are returned alongside it so you can audit every call. **Why is `totalContributors` not a 90-day-active count?** GitHub's per-period contributor stats endpoint (`/stats/contributors`) is unreliable on a cold cache — it returns `202` and rarely warms within a request cycle. Contributors are sourced from the stable all-time `/contributors` list instead. The field reflects repository-lifetime contributor breadth, not recent activity. **What does the `rationale` field contain?** It names the activity verdict and the weakest non-activity dimension, e.g. `"Overall: activity is Healthy; weakest dimension is issues (Moderate)."` It's designed for agent logs and human audit trails, not user-facing copy. **The Actor returned a rate-limit error — what do I do?** Add a GitHub token. See [Input](#input). A classic token with no scopes is free and takes under a minute to create at [github.com/settings/tokens](https://github.com/settings/tokens). **Found a bug or want a feature?** Open an issue on the Actor's **Issues** tab. Custom variations are available on request. # Actor input Schema ## `githubToken` (type: `string`): Read-only personal access or fine-grained token. GitHub's GraphQL API (the Actor's primary data source) rejects unauthenticated requests; Apify's shared IPs exhaust the anonymous REST quota (~60 req/hr) almost immediately. Without a token, the Actor returns rate-limit errors rather than verdicts. A classic token with no scopes works for public repos; a fine-grained token works for private repos. Recommended for Standby: set a GITHUB\_TOKEN environment variable on the Actor so it persists across restarts. ## `cacheTtlMinutes` (type: `integer`): How long a repository's fetched GitHub payload is reused before refetching. Lower = fresher reads; higher = fewer GitHub API calls. All five tools share the same cached payload per repo. ## `analysisWindowDays` (type: `integer`): Trailing window (30–365 days) over which issue and PR activity is measured. Shorter windows surface recent trajectory; longer windows reflect a steadier baseline. ## Actor input object example ```json { "cacheTtlMinutes": 20, "analysisWindowDays": 90 } ``` # API You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup. ## JavaScript example ```javascript import { ApifyClient } from 'apify-client'; // Initialize the ApifyClient with your Apify API token // Replace the '' with your token const client = new ApifyClient({ token: '', }); // Prepare Actor input const input = { "githubToken": "", "cacheTtlMinutes": 20, "analysisWindowDays": 90 }; // Run the Actor and wait for it to finish const run = await client.actor("joeslade/github-repo-intelligence-mcp").call(input); // Fetch and print Actor results from the run's dataset (if any) console.log('Results from dataset'); console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`); const { items } = await client.dataset(run.defaultDatasetId).listItems(); items.forEach((item) => { console.dir(item); }); // 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs ``` ## Python example ```python from apify_client import ApifyClient # Initialize the ApifyClient with your Apify API token # Replace '' with your token. client = ApifyClient("") # Prepare the Actor input run_input = { "githubToken": "", "cacheTtlMinutes": 20, "analysisWindowDays": 90, } # Run the Actor and wait for it to finish run = client.actor("joeslade/github-repo-intelligence-mcp").call(run_input=run_input) # Fetch and print Actor results from the run's dataset (if there are any) print("💾 Check your data here: https://console.apify.com/storage/datasets/" + run["defaultDatasetId"]) for item in client.dataset(run["defaultDatasetId"]).iterate_items(): print(item) # 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start ``` ## CLI example ```bash echo '{ "githubToken": "", "cacheTtlMinutes": 20, "analysisWindowDays": 90 }' | apify call joeslade/github-repo-intelligence-mcp --silent --output-dataset ``` ## MCP server setup ```json { "mcpServers": { "apify": { "command": "npx", "args": [ "mcp-remote", "https://mcp.apify.com/?tools=joeslade/github-repo-intelligence-mcp", "--header", "Authorization: Bearer " ] } } } ``` ## OpenAPI specification ```json { "openapi": "3.0.1", "info": { "title": "GitHub Repo Health Check (MCP Server)", "description": "Opinionated health verdicts for any GitHub repo—Actively maintained, Slowing, At-risk, or Likely abandoned—exposed as 5 MCP tools, with the raw metrics behind every verdict so your agent can see the why.", "version": "0.1", "x-build-id": "s6hQZ9ISOKmkVXKt6" }, "servers": [ { "url": "https://api.apify.com/v2" } ], "paths": { "/acts/joeslade~github-repo-intelligence-mcp/run-sync-get-dataset-items": { "post": { "operationId": "run-sync-get-dataset-items-joeslade-github-repo-intelligence-mcp", "x-openai-isConsequential": false, "summary": "Executes an Actor, waits for its completion, and returns Actor's dataset items in response.", "tags": [ "Run Actor" ], "requestBody": { "required": true, "content": { "application/json": { "schema": { "$ref": "#/components/schemas/inputSchema" } } } }, "parameters": [ { "name": "token", "in": "query", "required": true, "schema": { "type": "string" }, "description": "Enter your Apify token here" } ], "responses": { "200": { "description": "OK" } } } }, "/acts/joeslade~github-repo-intelligence-mcp/runs": { "post": { "operationId": "runs-sync-joeslade-github-repo-intelligence-mcp", "x-openai-isConsequential": false, "summary": "Executes an Actor and returns information about the initiated run in response.", "tags": [ "Run Actor" ], "requestBody": { "required": true, "content": { "application/json": { "schema": { "$ref": "#/components/schemas/inputSchema" } } } }, "parameters": [ { "name": "token", "in": "query", "required": true, "schema": { "type": "string" }, "description": "Enter your Apify token here" } ], "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/runsResponseSchema" } } } } } } }, "/acts/joeslade~github-repo-intelligence-mcp/run-sync": { "post": { "operationId": "run-sync-joeslade-github-repo-intelligence-mcp", "x-openai-isConsequential": false, "summary": "Executes an Actor, waits for completion, and returns the OUTPUT from Key-value store in response.", "tags": [ "Run Actor" ], "requestBody": { "required": true, "content": { "application/json": { "schema": { "$ref": "#/components/schemas/inputSchema" } } } }, "parameters": [ { "name": "token", "in": "query", "required": true, "schema": { "type": "string" }, "description": "Enter your Apify token here" } ], "responses": { "200": { "description": "OK" } } } } }, "components": { "schemas": { "inputSchema": { "type": "object", "properties": { "githubToken": { "title": "GitHub token (required in practice)", "type": "string", "description": "Read-only personal access or fine-grained token. GitHub's GraphQL API (the Actor's primary data source) rejects unauthenticated requests; Apify's shared IPs exhaust the anonymous REST quota (~60 req/hr) almost immediately. Without a token, the Actor returns rate-limit errors rather than verdicts. A classic token with no scopes works for public repos; a fine-grained token works for private repos. Recommended for Standby: set a GITHUB_TOKEN environment variable on the Actor so it persists across restarts." }, "cacheTtlMinutes": { "title": "Cache TTL (minutes)", "minimum": 1, "maximum": 240, "type": "integer", "description": "How long a repository's fetched GitHub payload is reused before refetching. Lower = fresher reads; higher = fewer GitHub API calls. All five tools share the same cached payload per repo.", "default": 20 }, "analysisWindowDays": { "title": "Analysis window (days)", "minimum": 30, "maximum": 365, "type": "integer", "description": "Trailing window (30–365 days) over which issue and PR activity is measured. Shorter windows surface recent trajectory; longer windows reflect a steadier baseline.", "default": 90 } } }, "runsResponseSchema": { "type": "object", "properties": { "data": { "type": "object", "properties": { "id": { "type": "string" }, "actId": { "type": "string" }, "userId": { "type": "string" }, "startedAt": { "type": "string", "format": "date-time", "example": "2025-01-08T00:00:00.000Z" }, "finishedAt": { "type": "string", "format": "date-time", "example": "2025-01-08T00:00:00.000Z" }, "status": { "type": "string", "example": "READY" }, "meta": { "type": "object", "properties": { "origin": { "type": "string", "example": "API" }, "userAgent": { "type": "string" } } }, "stats": { "type": "object", "properties": { "inputBodyLen": { "type": "integer", "example": 2000 }, "rebootCount": { "type": "integer", "example": 0 }, "restartCount": { "type": "integer", "example": 0 }, "resurrectCount": { "type": "integer", "example": 0 }, "computeUnits": { "type": "integer", "example": 0 } } }, "options": { "type": "object", "properties": { "build": { "type": "string", "example": "latest" }, "timeoutSecs": { "type": "integer", "example": 300 }, "memoryMbytes": { "type": "integer", "example": 1024 }, "diskMbytes": { "type": "integer", "example": 2048 } } }, "buildId": { "type": "string" }, "defaultKeyValueStoreId": { "type": "string" }, "defaultDatasetId": { "type": "string" }, "defaultRequestQueueId": { "type": "string" }, "buildNumber": { "type": "string", "example": "1.0.0" }, "containerUrl": { "type": "string" }, "usage": { "type": "object", "properties": { "ACTOR_COMPUTE_UNITS": { "type": "integer", "example": 0 }, "DATASET_READS": { "type": "integer", "example": 0 }, "DATASET_WRITES": { "type": "integer", "example": 0 }, "KEY_VALUE_STORE_READS": { "type": "integer", "example": 0 }, "KEY_VALUE_STORE_WRITES": { "type": "integer", "example": 1 }, "KEY_VALUE_STORE_LISTS": { "type": "integer", "example": 0 }, "REQUEST_QUEUE_READS": { "type": "integer", "example": 0 }, "REQUEST_QUEUE_WRITES": { "type": "integer", "example": 0 }, "DATA_TRANSFER_INTERNAL_GBYTES": { "type": "integer", "example": 0 }, "DATA_TRANSFER_EXTERNAL_GBYTES": { "type": "integer", "example": 0 }, "PROXY_RESIDENTIAL_TRANSFER_GBYTES": { "type": "integer", "example": 0 }, "PROXY_SERPS": { "type": "integer", "example": 0 } } }, "usageTotalUsd": { "type": "number", "example": 0.00005 }, "usageUsd": { "type": "object", "properties": { "ACTOR_COMPUTE_UNITS": { "type": "integer", "example": 0 }, "DATASET_READS": { "type": "integer", "example": 0 }, "DATASET_WRITES": { "type": "integer", "example": 0 }, "KEY_VALUE_STORE_READS": { "type": "integer", "example": 0 }, "KEY_VALUE_STORE_WRITES": { "type": "number", "example": 0.00005 }, "KEY_VALUE_STORE_LISTS": { "type": "integer", "example": 0 }, "REQUEST_QUEUE_READS": { "type": "integer", "example": 0 }, "REQUEST_QUEUE_WRITES": { "type": "integer", "example": 0 }, "DATA_TRANSFER_INTERNAL_GBYTES": { "type": "integer", "example": 0 }, "DATA_TRANSFER_EXTERNAL_GBYTES": { "type": "integer", "example": 0 }, "PROXY_RESIDENTIAL_TRANSFER_GBYTES": { "type": "integer", "example": 0 }, "PROXY_SERPS": { "type": "integer", "example": 0 } } } } } } } } } } ```