Diagnostics and recovery
Start with the operation receipt
In Settings > GitHub evidence, inspect a repository's coverage and open its refresh receipt, or use Connections > Refresh history. Copy the refresh reference before investigating or retrying. Expand a repository's Collection diagnostics to see requests started, list pages read, elapsed time, and each evidence category's completion or stopping reason. The same diagnostics are available through github_refresh_get in the CLI and MCP. Older receipts return diagnostics: null; missing counters do not mean no requests occurred.
Requests count calls actually started, including failed calls. List pages count successfully parsed list responses, including pages subsequently rejected for inconsistent totals or pagination. Repository metadata and branch-head reads are requests, not list pages. Counters describe the recorded collection attempt, not all earlier retries. Elapsed time includes network waiting and is not CPU time. Diagnostics are kept in refresh results, separate from observation equality, so timing variation does not create Activity changes.
New refresh receipts also record bounded change categories against the previous accepted source observation. Comparison happens in the accepting database batch before that observation is replaced. A first observation, unchanged evidence, and a missing legacy comparison are different states. Completion summaries distinguish access/feature coverage gaps from credential rejection, runtime failures, and collection bounds; a fully collected result can still contain failing CI or security findings. Activity entries retain source attribution when the linked receipt expires. The receipt and Activity read contracts share workspace authorization across browser, CLI, and MCP.
Search repository names within a receipt and choose Changed, Needs attention, or All results. Needs attention includes collection failures, access gaps, and cancellations; it does not turn failed CI into a collection failure. The initial filter prioritizes attention results, then changed results. Repository buttons in the summary clear the filters and move keyboard focus to that result. All retained results remain available through All or the same github_refresh_get read.
API failures include a server-generated support reference. Browser and CLI messages preserve it; hosted MCP command failures include error.reference. HTTP API errors also carry X-HQ-Support-Reference. A reference identifies a failed request, not proof that a write was rolled back. Inspect durable receipts or saved revisions before retrying an interrupted operation, and reuse the same refresh/event ID when its acceptance is uncertain.
Disabled sources, missing credentials, provider cooldowns, stale evidence, and overdue scheduling are distinct states. Schedule warnings use the workspace snapshot's server time and allow for bounded queue draining. A delay warning is a prompt to inspect progress, not proof that the collector is stuck. Browser closure does not stop hosted collection.
Find the corresponding logs
Inspect the exact serving Worker with Cloudflare Fleet first. In Workers Observability, enumerate available fields, then filter the relevant time window by the Worker and one of these application fields:
| Application event | Correlation and interpretation |
|---|---|
hq.request.failed | reference, bounded operation, HTTP status, safe classification, and elapsed time |
hq.monitoring.targets.limited | reference, workspaceId, connectionId, inspected page and target counts, elapsed time, and the stopping reason identify a bounded search that can continue; target URLs and search text are excluded |
hq.github.repository.started | refreshId, repositoryId, sourceId, workspaceId, and server-generated runId identify the claimed attempt |
hq.github.repository.completed | The same identities plus collection status, receiptRecorded, evidenceStored, capacityLimited, and diagnostic counters; incomplete collection can occur inside an otherwise successful Worker invocation |
hq.github.batch.completed | runId, scheduled/background trigger, processed count, elapsed time, and stop reason |
hq.push.interrupted | Pending workspace notifications were retained for retry; the warning contains no record bodies, identities, or exception text. Check the Durable Object binding, D1 outbox and scheduled repair before assuming an open socket is up to date |
hq.secrets.cleanup.interrupted | Expired encrypted input may remain in private staging; inspect scheduled maintenance and D1 recovery. Input expiry still prohibits use, and collection is attempted independently |
Each event has schemaVersion: 1. Correlate the event's platform invocation ID with Workers CPU/wall-time measurements and available database metrics. Application elapsed time cannot substitute for platform CPU. A repository start without a matching completion can indicate interruption; inspect invocation outcomes and the durable receipt before concluding why. Abrupt CPU or process termination can prevent final logs entirely. A scheduled batch summary includes recovery, scheduling, collection, and final recovery; setup failures produce a failed summary with no processed items. item_limit means the configured slice was consumed, not proof that a backlog remains. time_limit can mean insufficient time to safely start another repository, even before the wall deadline. drained means no eligible item was found; cooldowns, an existing claim, or disabled authority can still leave queued work.
Application logs accept only a typed, runtime-validated field allowlist. They omit tokens, credential references/digests, authorization and cookie headers, request/response bodies, repository names, provider URLs, branch names, commit messages, raw exceptions, and stack traces. Unexpected runtime/network errors are not mislabeled as request-limit failures. Do not paste raw platform log records into Activity or support messages; use the reference, fixed classification, and relevant counters. Diagnostic logging failure must never change whether an operation is accepted.
Recovery by outcome
- Permission or feature unavailable: review the selected repository and existing read-only grant; do not infer a clean scan or broaden permissions automatically
- Credential rejected or configuration invalid: an owner must repair the configuration using the protected secret boundary and documented rotation sequence
- Provider cooldown: honor the persisted retry deadline shared by identical credentials; repeated manual retries do not bypass it
- Page/request limit: counts are lower bounds; inspect workload and capacity policy before increasing the bound
- Response-size, malformed response, or invalid pagination: preserve the safety boundary and diagnose the provider response in an appropriately protected environment
- Timeout, interruption, or unexpected failure: inspect the correlated invocation and receipt, then allow leased work to recover or explicitly retry terminal work
- Overdue scheduling: verify the exact deployed handler and Cron configuration, credentials, source eligibility, and batch diagnostics before changing cadence
Do not restore an older passing observation merely to clear an error. Follow the GitHub recovery contract and preserve source revisions, authorization checks, leases, attempt limits, and credential cooldowns.
Cloudflare Free-plan compatibility
Official limits verified on 2026-09-06. Successful operation on Paid does not establish Free compatibility.
The read-only github_coverage projection adds bounded local D1 reads and response serialization only while its rows are visible. Its statement-count regression is independent of selected repository count and includes live authorization and revision rechecks. Source fanout and UTF-8 response limits reject oversized selections with an exact-connection fallback. These bounds do not measure billable rows, platform CPU or total observer traffic, so they do not establish Free compatibility. Coverage navigation adds no GitHub calls or background collection and does not relax the recorded Paid requirements below.
The read-only repository_credential_coverage command adds bounded local metadata reads and serialization, with no decryption, provider requests, polling, or background work. Its statement-count regression compares small and maximum-size selections and includes two metadata snapshots plus live authorization checks. Selection, source fanout, active credential rows, internal metadata, and response bytes are bounded. This is not a measurement of billable D1 rows, Worker CPU, or aggregate client traffic; Free compatibility remains unverified, and the existing Paid requirements are unchanged.
Overview's workspace_attention projection adds no provider calls. Each selected attention_connection read invokes two bounded Hookrelay operations or three bounded Endpoint Monitor operations, plus authorized local metadata reads. The browser selects at most two operational connections and does not poll them on an interval. Provider paging limits remain visible, responses are capped at 256 KiB, and explicit resource context is capped at 1,000 association rows. These application bounds are not measured platform CPU, total downstream database work or a spending ceiling; repeated manual reads and multiple observers still consume resources. No additional Free-plan exceedance or verified Free compatibility is established by this feature.
| Feature or operation | Free constraint | Evidence and consequence |
|---|---|---|
| Scheduled GitHub collection | Workers CPU: 10 ms per invocation on Free; the minute Cron receives 30 seconds on Paid | Hosted single-repository collection on 2026-09-06 recorded approximately 23-42 ms CPU, including a diagnostic scheduled pilot at 42 ms CPU and 4.18 seconds wall time. This is an observed Free allowance exceedance, not a fleet worst-case estimate. Sustained overruns can terminate invocations and exhaust recovery attempts |
| Scheduled GitHub external reads | Free: 50 external subrequests per invocation; Paid default: 10,000 | The twenty-repository slice projects 120 requests for single-page complete collections and caps fully paginated collections at 360. A local Workers fixture executes the full 360-call slice successfully. Both workloads exceed Free; the smaller single-repository HTTP slice does not by itself establish CPU or database compatibility |
| Scheduled GitHub database work | D1: 50 queries per Worker invocation on Free; 1,000 on Paid | A fifty-repository local D1 fixture on 2026-09-06 executes approximately 90-180 SQL statements per scheduled slice, counting every batch statement separately. Those slices exceed the documented Free query allowance and stay below Paid's allowance. An idle tick in the same fixture executes eight statements and no GitHub requests. These are application statement counts, not a measurement of Cloudflare binding subrequests, billable rows, or CPU |
| Stored application/invocation logs | Free: 200,000 events per day and 3-day retention; Paid: 20 million included per month and 7-day retention | At the target workload of fifty repositories refreshed every five minutes, two repository events per attempt plus one batch and one invocation event per minute project about 32,000 events per day before HTTP traffic, retries, other Workers, or future tracing. This logging projection alone fits Free; account-wide usage is separate |
| GitHub refresh receipts | Application retention is independent of platform logs | Completed historical receipts expire after the application's retention window except the source's latest receipt. References can outlive the corresponding platform logs; neither store is a permanent forensic archive |
Workers CPU, external/internal subrequests, D1 per-invocation queries and daily/monthly row allowances, GitHub rate limits, and logging quotas are independent. Fleet-wide daily D1 row reads/writes have not been measured by the statement-count fixture; a query can touch many rows and indexes. The scheduler's request cap alone does not establish Free support. Disabling scheduled collection and leaving GitHub sources disabled is a supported way to avoid background GitHub usage, at the cost of missing or stale evidence; it is not proof that the rest of the application meets every Free limit. No verified Free-compatible live collection configuration is claimed by the pilot. A Paid-to-Free downgrade requires that fallback or a separately verified collector redesign, not just a smaller external-request batch.
The checked-in and release-artifact Wrangler configurations limit every invocation to 2,000 ms CPU and 1,000 total subrequests. Workers Observability for the seven days ending 2026-09-07 recorded a scheduled CPU maximum of approximately 403 ms, leaving about five times the observed peak. The subrequest ceiling leaves headroom above the application's fully paginated 360-request scheduled slice while reducing the Workers Paid default of 10,000. Cloudflare terminates an invocation that exhausts either ceiling; the durable job and lease records remain the recovery authority, and a resource-limit outcome must be correlated before retrying or raising a bound.
Custom limits.cpu_ms and limits.subrequests require Workers Standard. A Free-oriented fork must omit the custom block and rely on the fixed Free ceilings of 10 ms CPU, 50 external subrequests, and 1,000 internal-service subrequests. That fallback does not make scheduled collection compatible: the observed CPU and documented 120 to 360 external-request slice remain Free exceedances, so scheduled collection and its sources must stay disabled unless a separately measured design is introduced. The execution-ceiling behavior and fixed Free limits were verified against Workers limits and Wrangler limits configuration on 2026-09-07.
Structured logs use the existing enabled Workers Observability configuration. This feature does not enable tracing, Logpush, exports, or an external logging service. API successes do not emit extra application logs. Store queries and retention are operator concerns, not a raw-log API exposed to workspace users. Retention and quota changes require an explicit update to this compatibility record.
Workspace push adds transactionally recorded notifications, membership checks, and delivery acknowledgements to this collector baseline. The scheduled regression fixture keeps these application statements below its bounded Paid budget; the idle path adds one pending-outbox query. Trigger writes also consume D1 row-write allowance and are not represented by application statement counts. These changes do not establish Free compatibility or remove the existing Free exceedances.
GitHub Activity summaries add a bounded repository-result read when a refresh finishes. Per-repository change comparison runs within an existing accepting statement, and receipt links do not increase GitHub API calls or add source-inventory reads to the Activity view. These costs remain covered by the scheduled statement-budget regression; they do not remove the recorded Free-plan exceedances. Opening a receipt explicitly reads its source's bounded history and selected result, independently of the Activity live-update subscription.
Repository-attributed GitHub events add a conditional association insert per audit batch, bounded by that run's repository selection. These retained links and their notification triggers consume D1 writes even after a receipt is pruned; unchanged scheduled runs still create no journal event or association rows. The repository overview's repository_context command reads bounded local association metadata and exact totals, without provider requests or credential resolution. Its small activity_feed query is separate from metadata invalidation, and neither runs while another repository section is mounted. Counts and JSON membership scans still consume CPU and D1 row work; these changes do not establish Free compatibility or remove the collector's documented exceedances.
Sources: Workers limits, Workers Logs, Workers pricing, and D1 limits.
Reviewed bulk expectations use local HQ metadata only, with no provider requests or polling. EXPECTATION_BULK_LIMITS bounds repository selection, request and saved review bytes, live unapplied reviews per actor, and expired-plan cleanup. The SQL uses JSON selections rather than expanding one bound parameter per field and repository. Apply is a fixed-size batch of statements, but affected repository rows, immutable Activity links, transfer clocks and push triggers still consume D1 row writes. Applied plans and operation receipts are retained; expired unapplied plan cleanup is bounded. These costs are not a spending ceiling and do not establish Free-plan CPU compatibility or remove the collector's documented Free exceedances. An interrupted response should be investigated through the original expectation review and receipt, not repeated batches with new IDs.
Recording a repository review outcome uses a fixed-size atomic HQ batch for the receipt, saved date, Activity and associations. The outcome is bounded by the shared command schema. Receipt history and the corresponding row writes, project clocks and push triggers are retained; they are not an account-wide storage or cost ceiling. Expectation resolution reuses bounded monitoring reads and existing GitHub collection commands and cooldowns, with no timed provider polling or new service bindings. These paths add no separately verified Free-plan compatibility; the deployment requirements above still apply. API failures retain the existing support-reference diagnostics, and a lost completion response can be checked using its original review ID.
Reviewed project organization follows the same local-only cost boundary. PROJECT_ORGANIZATION_LIMITS bounds selected assignments, used target projects, serialized inputs/reviews, pending reviews and cleanup. Apply can create projects, update selected project presentation fields and change selected repository associations in one atomic receipt-bound batch. It captures Activity against both affected project identities without rewriting prior history. Fixed statement counts do not make the associated D1 row writes, structural clocks or push triggers free, and no Free-plan CPU claim is implied. Inspect the original organization review after an interrupted response instead of issuing new batches.
On-demand release and deployment reads add at most one fixed GraphQL query and one immutable-SHA REST comparison per uncached collection. Pull-request and issue context adds at most two fixed GraphQL queries for bounded metadata and exact sampled PR signals. Neither changes scheduled GitHub work. Each per-enrolled-pair context cache lasts five minutes, and a shared credential-hash budget admits at most ten contextual collections per minute across both features. Cache leases, budget counters, acceptance and source notifications consume D1 reads/writes even though the provider operation is read-only. The bounded response parser and serialization also consume Worker CPU. These application caps are not platform CPU or billable-row measurements and do not establish Free compatibility or remove the scheduled collector's recorded exceedances. They use the existing Paid profile without new bindings, credentials, logging configuration or execution-limit changes.
On-demand fleet discovery and reviewed enrollment share the Work/Releases credential budget and cooldowns. Discovery uses one fixed GraphQL query per uncached page; review verification uses at most two within a shared deadline. The latest source cache is byte-bounded, and the HQ comparison scans only the bounded workspace inventory. Apply performs a fixed-size atomic HQ batch with no provider writes, but selected rows, identity bindings, receipts, immutable Activity links, structural clocks and push triggers consume D1 writes. Pending-plan and cleanup limits do not limit retained applied history. These are application bounds, not measured platform CPU or billable-row totals, and establish no additional Free compatibility or relaxation of the documented Paid requirements. API failures use the existing support-reference logs; successful discovery does not add raw provider bodies or credential identities to logs.
Repository operational checks use COVERAGE_LIMITS for a bounded provider read and an independently limited shared workspace budget. Accepted reads retain only minimized evidence and publish changed observation records. Cache leases, budgets, invalidation triggers and acceptance checks consume HQ D1 work even though the provider operation is read-only; the provider's own service and database work are additional costs. Subscription paging or resource bounds can leave coverage incomplete, and excess connection fanout fails before provider work. The browser performs no timed coverage polling and fleet assessment makes no per-repository provider calls. These logical limits are not measured platform CPU, billable rows or a global spending ceiling, and establish no additional Free compatibility or relaxation of the documented Paid requirements. No new bindings, credential scopes, log sinks or invocation ceilings are introduced.
Linked Hookrelay checks can consume up to eight subscription pages per connection, within the same twelve-call budget shared with Monitoring. The inventory read is reused for every selected linked subscription on that connection. It stops at the first complete page sequence, a disappeared entry, the page ceiling, total call budget or elapsed allowance. A larger page allowance permits deeper inventory verification; it does not raise the total provider-call or workspace-check budget. Compared with the former two-page allowance, an admitted check can do more parsing and authorization work in HQ and more subscription metadata reads in Hookrelay. Neither page count nor the retained result size measures that downstream work, and Free-plan CPU, KV and D1 compatibility remain unverified. An incomplete inventory cannot establish a unique name match or prove a subscription is missing; inspect the paginated Hooks workspace when a repository check remains limited.
Dependency maintenance uses cached paginated lists without provider calls. An explicit repository inspection projects at most twenty GitHub requests and four optional public npm reads, below the Free external-subrequest ceiling of fifty before unrelated invocation work. The complete hosted tree is capped at 12,000 entries, each decoded file at 1 MiB, and aggregate decoded files at 4 MiB. Git identity hashing, parsing and semantic-version analysis consume CPU; neither these caps nor the elapsed-time field measure platform CPU. A local D1 regression keeps list statement counts below fifteen, independent of page occupancy, but that is not billable-row measurement or hosted capacity proof. The existing shared credential budget and five-minute cache limit repeated provider reads, and accepted uncached inspections emit one bounded diagnostic without raw files. These changes add no schedule or credential grant and do not relax HQ's documented Paid requirements. Free CPU compatibility for hosted dependency inspection is unverified; omit hosted inspection and run the repository CLI to avoid that work, accepting absent or stale dashboard evidence. Official Workers limits and configuration semantics were checked on 2026-09-09: Workers limits and limits configuration.
Reviewed dependency PR submission uses HQ's Paid profile; its Free query-budget compatibility is unverified. A local Workers/D1 measurement on 2026-09-09 used approximately 55 service statements for one successful renewal: an authenticated owner, an existing scoped encrypted credential, one override, policy/manifest/lockfile inputs, fresh immutable reads, per-phase authorization and durable acknowledgements, base-head rechecks, and Activity attribution. The statement count exceeds the documented Free allowance of 50 queries per Worker invocation; Paid allows 1,000. However, batches combine statements into fewer binding calls, so this is a projected Free constraint, not an observed hosted quota failure. HTTP middleware and push-delivery overhead are additional. Reproduce the independent statement and binding-call bounds with npx vitest run test/dependency-operations.test.ts -t 'measures the authenticated write'. Neither counter measures billable rows, platform CPU, or hosted latency. See D1 limits, batch semantics, and Workers limits, verified 2026-09-09.
Until independently verified on Free, leave repository write credentials unconfigured: quota exhaustion can interrupt an accepted operation after an external effect, leaving a receipt that needs reconciliation. Keep cached visibility and use the repository/CI workflow to propose and verify changes outside HQ instead; hosted inspection also has unverified Free CPU compatibility. The Paid profile provides headroom for per-effect authority checks, durable operation recording, and safe recovery; no check is weakened to claim Free support. PR-head inspection adds a separate byte-bounded per-enrollment cache, not scheduled work. A submission permits at most twenty evidence reads and six operation calls, no registry calls, ten starts per workspace per five minutes, and a one-minute execution lease; reconciliation has a per-operation minute cooldown. Encrypted credential storage, retained receipts, cache writes, trigger work, and deliberate terminal diagnostics have independent storage/logging costs. The Worker CPU ceiling, log retention, and existing Paid profile are unchanged.
Reviewed hook setup adds exact workspace, repository, connection and provider checks, durable intent and receipt writes, repository/project links, Activity and coverage-invalidation triggers. One setup uses a bounded provider plan and apply; its provider caps GitHub inspection and installation requests independently. HOOK_LIMITS.PENDING_REVIEWS bounds live setup reviews per actor. Operation completion emits hq.hooks.setup with the operation reference, fixed state/reason, link completion and elapsed milliseconds; it excludes credentials and private provider material. Known routing-only or link-pending outcomes stay partial, and uncertain external writes stay indeterminate. There is no scheduled setup polling. Hosted Free CPU and D1-query compatibility are unverified; the existing Paid profile remains in force. Leaving the provider's provision grant disabled retains metadata linking and authorized routing operations without online installation. The provider contract documents its request bounds and recovery procedures; no deployment or grant is implied by this feature.
Hosted capacity verification
On 2026-09-06 an owner-approved hosted fleet of approximately fifty active repositories completed two unattended sweeps using the bounded Paid profile. Each sweep made 307 GitHub requests, with the full queue draining in approximately two minutes. Every repository had one attempt per sweep. Incomplete results reflected unavailable repository or endpoint access, not timeouts, rate limits, request/page bounds, or storage capacity. These observations describe that selected scope and provider state; they are not a guarantee for arbitrary repositories or deeper pagination.
A correlated twenty-repository scheduled invocation used 354 ms CPU and 30.09 seconds wall time; a nine-repository invocation used 129 ms CPU and 10.36 seconds wall time. An idle scheduled sample used 5 ms CPU. These are invocation samples, not a measured total CPU cost for an entire sweep. Some invocation and console rows were absent from the inspected log query; stored receipts established complete repository coverage, and no lossless-log or full-window health claim is made from those queries.
At that observed request count, twelve sweeps per hour project approximately 3,700 GitHub requests per hour before manual refreshes or other applications using the same quota. This is a projection from two sweeps, not measured hourly traffic. The observed repeat began approximately six minutes after the first: a five-minute source interval determines eligibility, and the minute scheduler can add a tick's waiting time. Browser polling does not drive collection or reset that eligibility.
Scheduled Hook configuration collection emits hq.hooks.coverage.source with the workspace, connection, accepted count, and complete/limited/unavailable/changed outcome, plus hq.hooks.coverage.completed with their shared runId, processed connections, stored observations, provider request count, elapsed time, and failure/bound flags. The source event includes inventoryLimitReason for a page limit, read budget, disappeared records, excessive future timestamp, or repeated cursor, and providerClockSkewMs for the largest observed positive provider clock difference. Pagination tolerates the bounded difference in COVERAGE_LIMITS.HOOK_CLOCK_SKEW_MS; freshness starts at the earlier of HQ's read start and every provider page timestamp. Clock skew never extends freshness, and an older page retains its original expiry. Excessive future timestamps leave inventory incomplete. An expired lease can be reclaimed. Incomplete reads publish unverified coverage; interrupted work leaves prior evidence to expire. These events contain no raw subscriptions, credentials, or provider exception text.
The Hook collector uses the existing Paid scheduled invocation. Its reproducible maximum statement estimate is 1 + SCHEDULE_CONNECTIONS * (3 + SCHEDULE_REPOSITORIES) before push delivery, other scheduled services, and trigger row work. With the defaults in COVERAGE_LIMITS, that is approximately sixty statements, exceeding the Free D1 allowance of fifty queries per Worker invocation. Its provider-call bound is SCHEDULE_CONNECTIONS * SUBSCRIPTION_PAGES; each call also consumes Hookrelay work. This is a code-derived projection, not a hosted Free quota measurement or billable-row estimate. The source/link queries are indexed and retained schedule state is one row per connection, but observation updates and notification triggers still incur row writes. Shared fleet backlog can exceed the evidence lifetime and correctly leaves stale coverage visible. Removing the cron trigger avoids background collection, including GitHub collection, while preserving explicitly requested reads; it sacrifices automatic freshness and is not a general Free-compatibility guarantee. Paid provides headroom for bounded background collection and guarded evidence acceptance. D1's fifty Free versus one-thousand Paid queries per invocation and Workers' plan-dependent CPU limits were verified on 2026-09-28 in D1 limits and Workers limits.
Dependabot timeline resource bounds
Workers and D1 limits verified on 2026-10-26 in Workers limits and D1 limits. Free permits 10 ms CPU per request, 50 external subrequests, and 50 D1 queries per invocation. Paid permits 1,000 D1 queries per invocation; this application's explicit CPU/subrequest settings remain independent of the platform defaults. Successful Paid operation does not establish Free compatibility.
A schedule inspection performs at most five external GETs, reads at most a 128 KiB YAML blob, bounds parsed YAML nodes and normalized entries, and retains at most 128 KiB of normalized evidence. Inventory returns ten repositories per page with an independent 2 MiB response bound. For fifty repositories, one complete refresh projects at most 250 provider GETs spread across fifty HTTP commands; it is not one 250-subrequest invocation. Two browser workers submit reads concurrently. The shared credential budget admits ten inspections per minute across all contextual readers, so that workload needs at least five budget windows when no other reader consumes the budget. Cooldowns, leases, unavailable credentials, cancellation, or other clients can extend completion. These are reproducible request projections from the named application limits, not observed provider throughput or a billing ceiling.
Projection runs in the browser and caps selected entries, per-entry candidates/occurrences, and total occurrences. Reaching a bound produces incomplete coverage instead of an overlap-free claim. Loading the view makes no external provider requests and adds no recurring schedule collector. Cache rows, indexes, and push triggers still consume D1 storage and row writes. For fifty retained cache rows at the maximum evidence size, normalized payload storage alone projects approximately 6.25 MiB, before indexes and other application data.
A reviewed schedule submission uses at most five provider inspection reads and six Git/PR calls, including base-branch checks. The authenticated local D1 fixture executes more than fifty and fewer than one hundred application SQL statements while retaining at most fifty binding calls through batches. The statement workload exceeds Free's documented fifty-query allowance; do not treat batching as a verified quota bypass. Paid is required for this guarded hosted write path, as with override maintenance. Per-request CPU, billed D1 rows, aggregate fleet traffic, and Free read-only compatibility remain unmeasured. The supported way to avoid this write workload is to use the timeline for inspection/drafts and edit the YAML through the repository's ordinary Git workflow; this sacrifices hosted PR creation without weakening its checks.
hq.dependabot.inspected identifies the read, workspace/source/repository, safe read reason, configuration state, request count, and elapsed time. hq.dependabot.operation records the operation reference, action, phase, outcome reason, request count, and elapsed time. Neither contains YAML or provider bodies. For a lost response, inspect the same saved receipt and use read-only reconciliation. Retention and access follow the existing operation history and workspace authority; a cache observation is not a permanent audit archive.