Track government contracts as events, not search results.

A government contract tracker is a versioned watchlist that detects new opportunities, material amendments, deadline changes, cancellations, award decisions, signed contracts, and post-award actions. A portal alert can tell you that a search has a new match. A dependable tracker also remembers the previous record, identifies what changed, decides whether the change matters, routes it to the right owner, and retains evidence of the alert.

That distinction matters because procurement is not one event. A sources-sought notice can become a solicitation; a deadline can move twice; a lot can be cancelled; an award decision can precede the signed contract; and later modifications can change the value, term, supplier, or performance status. A flat export shows current rows. A tracker shows the state transitions that require action.

The practical design has two loops:

1. discovery: run saved searches and incremental feeds to find newly relevant procedures; and
2. lifecycle monitoring: follow individual records, store source versions, detect material changes, connect outcomes, and continue watching after award.

No single government portal covers that full loop across the United States, European Union, and United Kingdom. The source mix, identifiers, history model, and publication delay all change by jurisdiction.

Government contract tracker: the short answer

Use official portal alerts when a small team needs a manageable number of searches in one market. Build or buy a normalized data feed when the team needs cross-source coverage, shared qualification rules, amendment history, deduplication, CRM routing, measurable delivery, or an auditable account view.

A minimum useful tracker should answer six questions:

• What appeared? A new planning notice, request for information, tender, solicitation, direct-award notice, result, or contract record.
• Does it fit? The buyer, geography, category, value, lot, eligibility, set-aside, and deadline satisfy a written pursuit rule.
• What changed? A field, document, relationship, or status differs from the last accepted source version.
• What requires action? The change affects the bid decision, response plan, account strategy, or reporting obligation.
• What was the outcome? The procedure was awarded, signed, cancelled, terminated, or remains unresolved.
• What may happen next? A contract end date, option, extension, performance notice, pipeline notice, or new procedure creates a supported recompete signal.

Do not call a saved-search inbox a complete tracker. Do not call a daily export a live database. Do not call a guessed supplier or renewal date a sourced fact.

The broader government contracts database guide explains how opportunity, award, contract, financial, and supplier records differ. This guide focuses on the recurring monitoring workflow.

What a government contract tracker actually tracks

Four products are often described with the same word even though they solve different problems:

• A search returns records matching filters at query time.
• An alert reports a new match or a portal-defined update.
• A tracker keeps state across runs, derives events, assigns owners, and records delivery.
• A system of record preserves the complete accepted history, provenance, and business decisions used downstream.

A lightweight tracker can be a watchlist plus email. A production tracker usually has five data layers:

1. watch definition: market, buyers, classifications, keywords, places, values, notice stages, exclusions, recipients, and urgency;
2. raw source observation: the payload or permitted document, retrieval time, source URL, request parameters, response metadata, and content hash;
3. source version: an immutable representation of the record as observed at a point in time;
4. normalized event: a new notice, amendment, deadline change, cancellation, award, contract change, or correction derived from two or more observations; and
5. delivery record: who received the event, through which channel, when, with which payload, and whether acknowledgement or follow-up was required.

The watch definition and source history must remain separate. Changing a keyword rule should not rewrite what the source previously published. Similarly, a source correction should not erase the version on which a sales team acted.

Track lifecycle state, not only open tenders

Opportunity trackers often stop at open or closed. That loses commercially useful context. Preserve the source-defined stage and add a cautiously derived workflow state such as:

• early signal;
• market engagement;
• planned competition;
• accepting responses;
• amended;
• deadline passed;
• cancelled before award;
• award decision reported;
• contract signed;
• in performance;
• changed after signature;
• completed or terminated; and
• possible follow-on detected.

The derived state must cite the source event that supports it. “Deadline passed” can be calculated from a reported deadline. “Likely recompete next quarter” is an estimate and should never be stored as if the buyer announced it.

Start with official alerts before building a feed

Official alerts are the fastest way to validate search logic. They expose the language buyers use, show how much noise a filter creates, and help a team learn which changes actually affect a pursuit. They are also convenience features, not contractual delivery guarantees.

SAM.gov: saved searches discover; follows watch records

In SAM.gov, Contract Opportunities saved searches can send notifications for new matching opportunities. Other SAM.gov domains can save searches but do not offer the same Notify behavior. To monitor a specific notice, sign in and follow it in Workspace. Followed-item email preferences can be immediate, daily, weekly, or none, subject to the account’s global Workspace setting. (SAM.gov saved-search notifications; following an opportunity; follow preferences)

This creates the two-loop pattern in the portal itself: a saved search discovers a notice, then Follow watches the selected record. It still does not provide one cross-account event history, field-level diffs, acknowledgement, or a delivery SLA.

TED: saved searches, alerts, notice alerts, and RSS

A signed-in TED user can keep up to 25 saved searches and 25 search alerts. Search-alert frequencies can be daily, weekly, fortnightly, or monthly. Saved searches also support RSS, and a notice alert sends an email when a related notice is published. (TED account features; TED search results and alerts)

The related-notice behavior is important. Under eForms, a Change Notice has its own notice identifier and version, then refers to the notice and version being changed. Do not assume every amendment is merely the same notice UUID with a higher counter. Retain the relationship fields as well as the new publication. (TED notice view; eForms schema)

Find a Tender: alerts plus a connected notice lifecycle

Registered Find a Tender users can save searches and choose email-alert frequency for new matching notices. Its value for tracking goes beyond discovery: current Procurement Act notice types extend from pipeline and market engagement through tender, award decision, signed contract, performance, change, termination, and procurement termination. Related releases share an Open Contracting ID, or OCID. (Using the enhanced Find a Tender service; Find a Tender notice types)

Contracts Finder should not be the lead source for new Procurement Act procurements. It remains relevant to procedures begun under the previous rules. Public Contracts Scotland, Sell2Wales, eTendersNI, buyer systems, and linked e-sourcing portals can still be necessary for territorial, lower-value, document, clarification, or submission coverage. (Contracts Finder publication update)

No single alert covers the full lifecycle. Discovery alerts can miss edits or related publications; tender amendments differ from post-award contract modifications; and every portal applies its own identifiers, schedules, and coverage rules.

Map official sources to the procurement lifecycle

The best source is determined by the event, not only the country.

United States

Use SAM.gov Contract Opportunities for covered US federal opportunity notices. Use SAM.gov Contract Awards for detailed procurement actions and USAspending for award-level discovery, transactions, obligations, recipients, and funding context. State, local, grant, subcontract, and classified opportunities require other sources.

The public SAM.gov Opportunities API requires an API key plus postedFrom and postedTo; the date window can span no more than one year and a page can contain up to 1,000 records. It returns the latest active version. GSA directs users to SAM.gov Data Services for all versions, and documents daily updates for active notices and weekly updates for archived notices.

The API documentation does not list a public modified-date filter. Polling only “notices posted yesterday” can therefore miss an amendment to a notice first posted weeks earlier. Re-harvest active posted-date partitions with overlap, maintain a watchlist of relevant IDs, or use the versioned Data Services route. Compare hashes and source fields locally.

European Union

Use TED for EU-level planning, competition, result, modification, completion, and change notices. Its Search API is anonymous; daily and monthly XML packages support bulk reuse. Daily packages are published Monday to Friday by 09:30 at the latest, so a monitoring schedule should follow the OJ S publication calendar rather than pretend every source is continuous. (TED data reuse)

TED’s Active and latest-version controls help interactive discovery but do not define complete history. Use explicit dates, related-notice references, and retained versions for tracking. The website’s “All notices” search and bulk routes are the safer starting points for historical reconstruction. (TED search and browse help)

United Kingdom

Use Find a Tender for the current central Procurement Act lifecycle. Its open OCDS release API can filter by notice ID, OCID, and updated window, returns up to 100 records per cursor page, and documents retry behavior for rate or service responses. The record-package route returns the releases, compiled release, and versioned release for an OCID. (Find a Tender release API; record API)

Poll updatedFrom and updatedTo with overlap, complete every cursor, and deduplicate by OCID plus release ID. Do not treat a party ID as a worldwide supplier key: UK open-contracting guidance says party IDs are unique within a release, not globally. (UK open contracting guidance)

For a fuller jurisdiction and field comparison, see Government Tenders Data: SAM.gov vs TED vs UK Procurement Sources.

Use stable keys and immutable events

A tracker should reconstruct what it knew at any cutoff. That requires immutable source versions and explicit relationships.

Keep the source’s real identifiers

Recommended keys include:

• SAM.gov Opportunities: notice ID as the source-record key; solicitation number as a separate discovery and correlation field; related or parent IDs and agency hierarchy where supplied;
• SAM.gov Contract Awards: contracting-subtier context, PIID, modification and transaction numbers, referenced IDV PIID, and solicitation ID where reported;
• USAspending: generated award ID, generated transaction ID, PIID and parent-award identifiers;
• TED: notice identifier, VersionID, OJ S publication number, Procedure UUID when present, lot IDs, and explicit previous or related-notice references; and
• Find a Tender: OCID for the contracting process, release ID for the publication, notice ID, notice type, and lot or contract identifiers.

Titles are labels, not keys. Supplier names, descriptions, values, dates, and classifications can help rank a candidate link, but they should not silently create an exact relationship.

Store observations separately from business events

The source can republish a record without changing a meaningful value, and the same meaningful change can appear in more than one route. Separate these concepts:

• source_observation: one retrieval of one payload;
• source_version: a unique semantic source state after canonicalization;
• tracker_event: the classified difference between accepted states;
• watch_match: the event’s relevance to a saved rule or account; and
• alert_delivery: the notification and acknowledgement history.

Every event should include the old value, new value, source field, source timestamp when available, first-observed timestamp, record and version keys, classifier version, severity, and source link. Keep source_updated_at distinct from observed_at: one describes the publisher’s record, the other your collection.

Treat cross-source joins as evidence

An opportunity-to-award relationship can be:

• declared: the source publishes the relationship;
• exact: stable identifiers agree under the source’s documented rules;
• reconciled: a deterministic combination of agency, solicitation, lot, supplier, and date supports the link;
• candidate: several weak fields make the link plausible; or
• unlinked: no defensible relationship is available.

Store the method, confidence, and evidence. A missing link is better than a false winner.

Detect amendments without creating false alerts

The central tracker operation is not “download today’s rows.” It is “compare the new accepted state with the previous accepted state at the same grain.”

Normalize presentation before comparing meaning

Source payloads can change because of whitespace, HTML, field order, array order, translated labels, tracking parameters, or serialization. Before computing a semantic hash:

1. preserve the untouched raw payload;
2. parse values into typed fields without overwriting the source text;
3. normalize timezones while retaining the reported value and timezone;
4. sort arrays only when order has no source meaning;
5. normalize URLs cautiously and retain both original and canonical forms;
6. compare attachment names, URLs, sizes, checksums, and retrieval status; and
7. version the normalization and diff rules.

Do not reduce the whole record to one changed/not-changed flag. Produce field-level deltas, then classify their operational effect.

Changes that usually deserve explicit rules

At minimum test:

• response, clarification, presentation, and site-visit deadlines;
• procedure status, cancellation, suspension, and reactivation;
• notice and procurement stage;
• buyer, contracting office, contact, and submission route;
• scope, quantity, lots, options, term, place, and estimated value;
• NAICS, PSC, CPV, set-aside, eligibility, and participation conditions;
• evaluation criteria and award method;
• attachments, tender-document links, and access restrictions;
• related, previous, parent, and replacement notices; and
• award, contract, change, performance, completion, or termination publications.

A deadline moving later still matters. It can change the bid plan, signal a clarification or document change, and affect downstream calendar commitments. A deadline moving earlier should normally bypass a digest.

Suppress noise without erasing evidence

Alert suppression should operate after version retention. Combine repeated observations of the same semantic version, group changes published in a short configurable window, and send one event with a complete delta. Keep the suppressed observations in the audit trail.

Severity should be watch-specific. A contract award may be an immediate account alert for a named competitor, a daily result update for market research, and irrelevant to a team tracking only open bids.

Track awards and contract changes separately

Tender amendments occur before the contract is signed. Contract modifications occur after award or execution. Mixing them creates bad timelines and misleading alerts.

US award and transaction tracking

SAM.gov Contract Opportunities can include Award Notices, but they are not the full federal contract-action history. Use the separate SAM.gov Contract Awards API for base actions and modifications. It exposes fields such as PIID, solicitation ID, modification number, reason for modification, last-modified date, and referenced IDV. Solicitation ID can support an opportunity-to-award correlation, but the official documentation does not promise a complete one-to-one join.

Use USAspending transaction history when the question is how obligations and reported award actions changed over time. USAspending is not an opportunity-alert service. A financial transaction is not automatically a tender amendment, renewal, or operational scope change, and its action amount is not the same as the cumulative current award value.

Publication time also differs from event time. USAspending’s data guide says contract awards and modifications are generally visible within about five days, while public Department of Defense and US Army Corps of Engineers records have a 90-day delay and specified emergency reporting can take longer. A tracker should label expected source lag rather than raise a pipeline incident every time a newly signed action is not immediately public. (USAspending data sources; About the data)

The separate awarded government contracts guide explains how to reconcile SAM.gov and USAspending and avoid false dollar totals.

TED outcomes and changes

TED publishes Result, Contract Modification, Completion, and Change notice families. Link through the explicit notice and procedure relationships, not merely the title. Because a change publication can receive a new notice identifier, retain previous-notice references and version IDs together.

UK decision, signature, change, and termination

Find a Tender makes the lifecycle unusually explicit:

• UK6 Contract Award Notice records the intention to enter into a contract and normally precedes signature;
• UK7 Contract Details Notice follows contract entry and represents the signed-contract stage;
• UK9 Contract Performance Notice reports defined performance information;
• UK10 Contract Change Notice reports a qualifying post-signature change;
• UK11 Contract Termination Notice follows completion or termination; and
• UK12 Procurement Termination Notice reports a procurement ended before contract signature.

Do not label UK6 as an executed contract. Do not treat UK10 as a simple editorial revision of UK7. Those distinctions affect win-rate, signed-value, contract-change, and incumbent analysis. (Find a Tender notice types; UK contract modifications guidance)

Estimate recompete timing without inventing a renewal

A contract tracker can surface likely follow-on demand, but it cannot turn circumstantial signals into a promised solicitation.

Strong evidence includes:

• an official pipeline, planned-procurement, prior-information, or market-engagement notice;
• a new sources-sought or request-for-information notice from the relevant buyer;
• an explicit contract end date after accepted options and modifications;
• a published extension, bridge action, termination, or contract-change notice;
• a replacement or related procedure ID; and
• a buyer forecast or acquisition-plan reference tied to the requirement.

Weaker signals include recurring descriptions, the base-period end date when options exist, a spending ceiling, an annual budget pattern, a supplier’s last transaction, or a similar classification appearing at the same agency. Use them to rank research, not to assert that a recompete exists.

A defensible output separates:

• the observed fact and source;
• the estimated window;
• the reasoning rule;
• the confidence;
• contradictory evidence; and
• the date on which the estimate should be reviewed.

For example: “Possible follow-on in Q2 2027, medium confidence, based on the current reported end date and a new market-engagement notice” is reviewable. “Renews in Q2 2027” is not supported unless the source says so.

Build a daily government contract tracking pipeline

“Daily” should describe a controlled publication and delivery cycle, not a claim that every source is live or complete.

1. Define the coverage contract

List the jurisdictions, portals, buyers, notice types, award layers, date fields, classifications, languages, document scope, historical start, refresh schedule, and exclusions. State whether the product tracks all collected records or only qualified watchlists.

2. Schedule by source behavior

Collect after the expected publication window, then run a later reconciliation pass. TED follows weekday OJ S editions. SAM.gov documents daily active and weekly archived opportunity updates. Find a Tender exposes updated windows and cursors. USAspending’s apparent freshness includes agency reporting and disclosure delay.

3. Poll with overlap

Use bounded source windows with an overlap large enough to catch late publication and corrections. Persist the exact window, parameters, page or cursor chain, response counts, and completion state. Upsert by source keys; never assume the same date window contains only new rows.

For SAM.gov Opportunities, re-harvest relevant active posted-date partitions or versioned files because the public API lacks a documented modified-date filter. For Find a Tender, overlap updatedFrom and updatedTo, then deduplicate by release identity. For TED, retain every published and related notice rather than relying on a current-only view.

4. Land immutable raw evidence

Store the permitted source payload or file before normalization, with retrieval timestamp, source timestamp, URL, parameters, media type, size, checksum, and collector version. Hash attachments when they can lawfully and reliably be retrieved. Record an unavailable or access-controlled document as a state, not as an empty successful download.

5. Prove extraction completeness

Validate page and cursor completion, duplicate keys, response totals, newest and oldest source dates, expected source partitions, and schema readability. Quarantine a partial edition instead of silently publishing it as complete.

6. Normalize without erasing the source

Map common concepts such as buyer, supplier, classification, place, stage, deadline, value, lot, and relationship. Retain raw field names, codes, currencies, tax basis, languages, timestamps, and provenance. A SAM notice type, TED eForms notice, and UK notice code are not interchangeable labels.

7. Derive and qualify events

Compare the new semantic version with the prior accepted version. Classify the delta, match it to each watch definition, and calculate watch-specific severity. Run deterministic exclusions before expensive enrichment or fuzzy ranking.

8. Route, acknowledge, and retry

Deliver immediate events, scheduled digests, CRM tasks, or data exports according to the watch. Use an idempotency key so a delivery retry does not create a second task. Retain the delivery status, payload version, recipient, retry count, and acknowledgement.

9. Reconcile and backfill

Rerun recent windows, compare portal counts or prepared files, revisit unresolved award links, and backfill when a source publishes late. A green collector only proves that a request succeeded; it does not prove that the source period is complete.

WebTruffle’s free government tenders and RFPs dataset and government contract awards dataset are daily publication-window editions for their stated sources and stages. They are not represented as live master inventories. A production tracker should combine editions into retained state and verify that the published scope matches the required markets.

Define tracker SLAs and quality checks

Measure the outcome delivered to users, not only successful HTTP requests.

Separate source lag from pipeline latency

Use at least four timestamps:

• source event or effective time;
• source publication or update time;
• first successful observation time; and
• accepted delivery time.

Then report source publication lag separately from collection, processing, and delivery latency. If a source withholds a class of records for 90 days, a same-day ingestion SLA cannot make those records public sooner.

Useful service measures

A tracker quality report should include:

• expected source editions or partitions received;
• pages and cursors completed;
• newest observed source-update time by source;
• unique records, versions, material events, and deliveries;
• duplicate and replay rates;
• percentage of tracked records with retained prior state;
• deadline and cancellation detection coverage in reviewed samples;
• alert precision and suppressed-noise rate;
• unmatched and candidate opportunity-to-award relationships;
• attachment retrieval and change-detection coverage;
• delivery latency by priority; and
• failed, retried, acknowledged, and overdue alerts.

Targets should follow the source and commercial risk. Illustrative acceptance rules might require every expected source partition to have a completed manifest, every immediate event to have an idempotent delivery record, and every published deadline change in a review sample to have a field-level delta. They should not promise zero source delay or perfect opportunity-to-award linking.

Use the web scraping data quality framework for completeness, validity, freshness, duplicates, and source fidelity. Use the monitoring runbook to separate a delayed source, partial extract, broken parser, and failed delivery.

Choose portal alerts, a dataset or a custom tracker

Choose the smallest model that meets the decision.

Use portal-native alerts when

• one or two people monitor a limited number of searches;
• one jurisdiction is enough;
• the portal’s filters and frequency fit the workflow;
• manual review and follow-up are acceptable; and
• consolidated history, shared routing, and service metrics are not required.

Use a normalized dataset when

• the team needs a repeatable table across sources;
• analysis, enrichment, or a dashboard is the main output;
• source-specific collection is not a strategic capability; and
• the dataset’s publication window, fields, markets, and history are explicitly sufficient.

The consumer still needs to accumulate editions and define event rules. A daily file does not automatically become a stateful tracker.

Build a custom tracker when

• source coverage or history is bespoke;
• account-specific qualification determines severity;
• amendments must be diffed at field or attachment level;
• results must create CRM, workflow, or product events;
• audit, acknowledgement, and delivery SLAs matter; or
• proprietary enrichment and outcome learning are part of the advantage.

The core build is not the dashboard. It is the source-aware state model, repeatable collection, version retention, material-change policy, and monitored delivery path underneath it.

Frequently asked questions