USAspending Contract Runway & Extension Monitor

Track reported federal contract end dates and the changes that affect your capture watchlist. Get incumbent organizations, current and potential performance end dates, funding facts and exact before/after changes from the official USAspending API.

Start with a small run

1. In Input, choose Find contracts by keyword or filters, then add your keywords. Leave keywords blank to try the small software-contract demonstration, or open Refine your search to filter by industry, agency or company.
2. Keep Maximum results to save at 5 for your first run. Maximum contracts to check bounds attempted lookups; successful checks can be billed even when your output filters hide them. Leave Include recent contract transactions off for the fastest first run.
3. Click Start. In Output, open Start here: capture brief (HTML) for a readable summary and recommended next steps, or open Saved contract observations to sort and export the data.

To monitor known contracts instead, choose Recheck contracts by ID and paste their USAspending IDs into Contract IDs to recheck. For later runs, reuse the generated Ready-to-recheck watchlist input so comparisons retain their previous observations. The other settings are grouped into optional sections; their defaults are suitable for the first run.

Simple introductory pricing

$1.50 per 1,000 completed contract checks, plus $0.00005 per run. Standard-run platform usage, capture briefs, alerts, snapshots and bounded transaction history are included. There is no monthly rental or feature surcharge. For example, five completed checks cost $0.00755 and 1,000 completed checks cost $1.50 plus the start fee for each run. Use bounded batches for larger workloads.

One check means one successfully retrieved, normalized and stored canonical contract observation. Unchanged checks and checks hidden by onlyAlerts or the horizon filter still count. Rechecking the same contract in a new run is a new check. Failed or unavailable award lookups and duplicate aliases within a run are not billed as completed checks; the start fee still applies to an empty or failed run.

Open All completed contract checks in Output to see every stored observation, including quiet checks, with links to the full records. The dataset and capture brief contain only observations matching your output filters. RUN_SUMMARY.billing reports confirmed checks; a storage or charging failure can leave an accessible observation that was not billed.

Set Maximum charge per run in Apify run options to control spending. The Actor stops before another source lookup when it cannot afford another check and preserves completed output. maxResults limits dataset rows; use maxAwardsToScan to bound checks, especially with alert-only filters. A low spending limit may produce partial coverage. The introductory rate has no scheduled increase; review any future pricing notice in Apify before running.

Capture briefs and useful monitoring

The Actor now produces a capture review queue, a standalone HTML brief, a CSV shortlist and incumbent rollups. Each queued contract explains why it deserves review and links to source evidence.

• Target discovery: Filter by NAICS industry prefix, exact top-tier awarding agency, incumbent organization and reported obligation range. Sort by value, modification date or current end date. Filters run at the source before detail retrieval.
• Separate date contexts: A current end in 2027 with a potential end in 2030 receives an option-context review label. A potential end inside your horizon receives a separate planning-review label. Neither establishes a future RFP or that all contractual options are exhausted.
• Inspect real transactions: Enable includeTransactions for bounded recent modification records, action descriptions and funding changes. History can be complete, sampled or unavailable; lookback totals cover only sampled records. If a later history page fails or exhausts the request budget, earlier records remain available with an explicit warning and incomplete coverage. Historical end dates are not reconstructed.
• Reduce repeat noise: onlyAlerts saves first observations (when enabled), material obligation changes, incumbent/date changes, new latest-transaction identities and entry into configurable review windows. A current end date becoming missing or being restored also alerts, without inventing an extension length. Countdown-only window entries can alert even when the source facts remain unchanged. Successful suppressed observations still update state. Alert IDs distinguish separate occurrences of a repeated change; comparison against the same prior observation keeps the ID stable.

A targeted search example:

{
  "mode": "search",
  "naicsCodes": ["541512"],
  "awardingAgencies": ["Department of Veterans Affairs"],
  "minObligationUsd": 1000000,
  "activityDateType": "last_modified_date",
  "sortBy": "Last Modified Date",
  "sortOrder": "desc",
  "includeTransactions": true,
  "maxTransactionsPerAward": 5,
  "maxResults": 10,
  "maxAwardsToScan": 10,
  "maxHttpRequests": 40
}

No hidden keyword is added to an industry, agency or incumbent search. With no discovery filters, the default small demonstration searches for software. An activity window is still applied; it is not a complete expiry inventory.

Read the outputs Start here: capture brief (HTML), Review brief & incumbent totals (JSON), Review queue spreadsheet (CSV) and Ready-to-recheck watchlist input after a run. All completed contract checks includes the full stored observations even when output filters suppress them. A quiet run still produces follow-up input for its original watchlist, including unavailable awards. Discovery also retains successfully evaluated contracts suppressed by the horizon filter. Follow-up input preserves your horizon, first-observation setting and work limits. An empty discovery without any evaluated contracts has no watchlist artifact.

The watchlist artifact uses your named store when one was supplied. Otherwise it includes updated portable snapshots; use the newest generated input after each recheck, or use a named store for recurring monitoring. No schedule is created. maxHttpRequests caps all search, detail, transaction and retry calls. maxTransactionRequestsPerAward separately caps transaction attempts, including retries, at eight per contract by default (adjustable from one to eight). Reaching it keeps the available sample, marks history incomplete with stopReason: "transaction_request_limit", and continues to the next contract. It adds no fee. Use transaction pages of ten or more for larger samples.

Use cases

• Recheck a contract watchlist without a SAM.gov key.
• Separate a current end date from a later potential end date before prioritizing research.
• Detect observed extensions, shortened dates and changes in reported obligations or outlays.
• Export structured facts with source links, quality flags and coverage information.

Reported dates can change. An approaching date does not confirm a new solicitation or recompete. Option-date gaps do not prove that an option remains legally available. Obligations, outlays and contract ceiling values represent different financial facts.

Inputs

Use search to discover a bounded set of contract awards by keyword and award-activity dates. Use watchlist for recurring checks of known numeric USAspending IDs or full CONT_AWD_ identifiers.

{
  "mode": "search",
  "keywords": ["software"],
  "maxResults": 20,
  "maxAwardsToScan": 50,
  "maxPages": 2,
  "horizonDays": 365
}

Activity dates filter the source's award activity; they do not select every contract expiring in a period. The horizon is applied after detail retrieval. onlyWithinHorizon saves only contracts whose current end date is between the reference date and the horizon, inclusively. Filtered contracts still count toward evaluation limits and update their snapshots.

For automatic comparison, supply monitorStoreName with an explicit key-value store name and reuse it on later runs. Run only one monitor at a time per store. You can also pass the previous run's SNAPSHOTS array as previousSnapshots; matching input snapshots take precedence. No schedule is created by this Actor.

maxResults, maxAwardsToScan, maxPages and maxRuntimeSeconds independently bound work. Defaults save at most five contracts, evaluate at most ten and allow two minutes, with at most 30 HTTP requests. No proxy is used. Large inputs can finish partially when a bound is reached.

Output

Start with the HTML brief, then use the table or CSV for your shortlist:

Output	When to use it
Start here: capture brief (HTML)	Read the summary, dates, funding, review reasons and recommended next actions.
Saved contract observations	Scan the default shortlist; switch views for dates and funding, changes and evidence. Export CSV, Excel or JSON from the dataset.
Review queue spreadsheet (CSV)	Download contracts that need review under the selected rules. Watch-only contracts remain in the dataset when your filters allow them.
All completed contract checks	Inspect every stored observation, including successful checks hidden from the dataset. Follow each observation link for its full record.
Ready-to-recheck watchlist input	Copy this input into a new run to check the same contracts again while retaining comparison state.

An empty alert table can be normal: contracts may have been checked successfully without a new alert. The brief separates completed checks from saved results and explains coverage limits. A partial run does not mean every matching contract was checked.

The dataset contains one row per canonical contract matching your output filters. The JSON retains the full evidence and stable field names for integrations; table labels are designed for reading. Each row includes:

Field	Meaning
awardId, recipientName, recipientUei	Contract and incumbent organization identity
currentEndDate, potentialEndDate	Separate reported performance dates
daysToCurrentEnd, daysToPotentialEnd, optionDateGapDays	Calendar-day calculations against asOfDate
expiryWithinHorizon, expiryBucket	Transparent current-date window labels
totalObligationUsd, totalOutlayUsd	Committed amounts and reported outlays, kept separate
baseAndExercisedOptionsUsd, baseAndAllOptionsUsd	Source contract value fields; not a revenue forecast
changeType, changes	Baseline, unchanged or changed facts with before/after values
dateChangeType, currentEndDateDeltaDays	Observed extension/shortening compared with the last successful observation
dataQualityFlags, provenance	Missing/inconsistent dates and source field paths
sourceUrl, sourceApiUrl, observedAt	Direct evidence links and observation time

A shortened example from a genuine run (reported facts can change):

{
  "awardId": "CONT_AWD_36C10B22N10030033_3600_VA11816D1003_3600",
  "recipientName": "GOVCIO, LLC",
  "currentEndDate": "2027-06-12",
  "potentialEndDate": "2027-06-12",
  "totalObligationUsd": 79659321.52,
  "sourceUrl": "https://www.usaspending.gov/award/CONT_AWD_36C10B22N10030033_3600_VA11816D1003_3600",
  "capture": {
    "category": "potential_end_in_window",
    "reviewPriority": "review_now",
    "recommendedNextStep": "Review acquisition planning and published notices for the reported potential end window. Confirm dates with the agency before treating this as a bid opportunity."
  }
}

The first observation is baseline. Only tracked factual changes produce changed; a countdown moving by one day does not. Unavailable awards are listed in RUN_SUMMARY.failures and are never declared removed. Missing monetary data stays null; a real zero stays zero.

The key-value outputs are RUN_SUMMARY (coverage, limits, requests, failures and structured health warnings) and SNAPSHOTS (portable comparison state). Capped or failed searches are explicitly incomplete. No private credentials, executive compensation, DUNS numbers, personal contact details or street addresses are collected in output.

Python API integration

Use your Apify API token to run the Actor and read its dataset:

import os
from apify_client import ApifyClient

client = ApifyClient(os.environ["APIFY_TOKEN"])
run = client.actor("thescrapelab/usaspending-contract-runway-monitor").call(run_input={
    "mode": "search",
    "keywords": ["software"],
    "maxResults": 20,
    "maxAwardsToScan": 50
})
for row in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(row["recipientName"], row["currentEndDate"], row["potentialEndDate"])

Source: USAspending.gov and its public API. This product is independent of the U.S. government. Source reporting can be incomplete or delayed, and reported performance dates are not procurement commitments.

Support

Use the Actor’s Issues tab for support. Include the run ID and affected public award ID. Never include API tokens.

Safe recurring monitoring and recovery

Cloud runs sharing a monitorStoreName coordinate through a server-side lease. An overlapping run fails with MONITOR_STORE_BUSY before collecting source records; retry after the active run finishes. Ownership is checked before shared snapshot writes and renewed during longer runs. A hard stop can leave the lease held for up to two minutes. Local processes still require one writer per store.

For a bounded watchlist, use the newest Ready-to-recheck watchlist input after each run. It moves attempted IDs behind unattempted IDs, so a small scan limit can progress through the whole watchlist over successive runs. Successfully resolved numeric IDs become stable canonical IDs. Failed numeric lookups retain potentially matching portable snapshots for later comparison. If ambiguous portable state exceeds the supported limit, the brief explains how to split the input and recover from the original input plus current snapshots; an invalid oversized follow-up input is not generated.

RUN_CHECKPOINT retains committed progress and portable snapshots. On a graceful abort or migration notice, the Actor stops source work and exports partial results with an explicit interruption status. Start a new run with WATCHLIST_INPUT to continue monitoring; if interruption occurred before any observation, reuse the original input. Restarting or resurrecting the same run preserves its prior artifacts and refuses silent replay. Dataset delivery and snapshot updates are separate operations, so exactly-once delivery and automatic scan resumption are not guaranteed. A hard kill can interrupt the last in-flight write.

When raising maxRuntimeSeconds, also set the Apify run timeout at least 60 seconds higher. Source input cannot extend a shorter platform timeout.