US WARN Layoff Notice Aggregator & Delta Monitor

Aggregate US state WARN Act layoff & plant-closure notices into one normalized schema, and get a delta feed of exactly what changed since your last run: new notices, updated notices (employee count / effective date / type revised), and removed notices.

Every state publishes WARN filings in a different shape (Socrata, CSV, HTML, Excel) with different column names and layoff-type wording. This actor unifies them so you can monitor layoffs across states from a single, stable dataset — no logins, no API keys.

What v1.1 changed (2026-08-01 validation pass)

Every source is now checked live, before a single row is billed, and every row carries the outcome of every requested state. Concretely:

• A dead state is loud. If Texas fails and Oregon succeeds, every emitted row carries run_complete = false, run_states_failed = "TX" and the error text. Previously the run emitted Oregon rows and nothing else, indistinguishable from "Texas had no layoffs". If every requested state fails, the run fails and nothing is billed.
• The delta engine no longer invents changes. Oregon's WARN number is not one-per-row — 330 live rows carry only 196 distinct WARN numbers, and WARN 9434 alone covers 19 separate Kroger store closures. Keying on it made a re-run against byte-identical upstream data report 146 "updated" notices, complete with invented headcount changes. A re-run now reports zero.
• maxResults is split evenly across states. maxResults: 100 over ["OR","TX"] used to return 100 Oregon rows and zero Texas rows with no error. Rows now also carry source_truncated when a state was cut short.
• Source freshness is on every row. source_last_notice_date and source_stale_days. Oregon's export measured 4 days since its newest notice on 2026-09-05 — a fact a buyer needs, and one no amount of offline testing could surface.
• Nine fields that were fetched and thrown away are now emitted — see the table below.
• An unrecognised layoff-type value fails the run instead of being silently bucketed to null.
• Nothing was removed or renamed. Every 1.0 field still means exactly what it meant.

Who it's for

• RevOps & recruiting / staffing — catch fresh layoffs the day they're filed to source candidates or reach affected employers before competitors.
• Economic & labor-market researchers — build a clean cross-state layoff time series without hand-scraping each agency portal.
• Commercial real estate (CRE) & site selection — flag closures that free up facilities and shifts in regional employment.
• Investors & risk / supply-chain teams — track distress signals by company, county and sector.

Coverage

Texas changed source in October 2026 — fresher rows, same keys

Texas used to come from the Socrata copy data.texas.gov/resource/8w53-c4f6. That copy stopped updating on 2026-07-07: its newest notice was 2026-06-23, so by October every Texas row carried source_stale_days above 100. This actor now reads the Texas Workforce Commission's own yearly workbooks (one xlsx per year, 2020 to date), which TWC updates within days: on 2026-10-10 the newest notice was 2026-10-06, and TWC listed 37 notices filed after the Socrata copy froze plus 26 older ones that the Socrata copy never had.

The change is append-only, and a scheduled delta does not need resetting. The delta keys (notice_key, identity_key) are built from the same company, city and effective-date values. Measured against the full Socrata registry, 2,363 of 2,368 notices reproduce their exact key. Every stored delta baseline was re-checked: 33 of 33, 33 of 33 and 69 of 69 keys matched, with zero removed rows. What genuinely differs:

• TWC has corrected a handful of notices since the Socrata copy froze. Examples: FreshRealm (Lancaster) went from 176 to 161 workers, Cottonwood Creek's notice date moved from 09-24 to 09-26, and a few company names were completed ("Nucor (Longview)" became "Nucor Steel (Longview)"). A delta run reports a corrected count or date as updated. A renamed company has a new key, so it shows as one removed row plus one new row. 5 notices across the whole registry are affected.
• Provenance fields name the new source. On rows read from TWC, source_url is the TWC workbook, source_dataset_id is twc-warn-act-listings, and source_format is twc_xlsx. Their meaning is unchanged.
• New fields source_backend, source_failover and source_failover_reason say which source served each Texas row (they are null on Oregon rows).

Notices before 2020. TWC publishes no workbook before 2020, but the Socrata copy holds 153 notices from 2019. Full-history runs still return them, labelled source_backend: "socrata_archive", so nothing that used to be returned disappears.

If TWC is unreachable, for example during an outage or bot-protection block, Texas is served from the Socrata copy exactly as before. Every such row carries source_failover: true and the reason, and source_stale_days honestly reports the older date. If TWC answers but its files no longer match their measured shape (a renamed column, a missing year, unparseable dates), Texas fails instead. The stale copy is never substituted for a source that answered wrongly.

Oregon changed source in September 2026 — what that means for your rows

Oregon's Socrata dataset data.oregon.gov/resource/ijbz-jpx8 began answering HTTP 403 authentication_required on every request around 2026-08-20 and is gone from the Socrata catalog. This actor now reads Oregon from the state's own HECC Rapid Response Activity Tracking System export instead — still keyless, still no login.

The change is append-only. Nothing was removed or renamed. Every field the Socrata leg emitted is still emitted, with the same name and the same meaning, and the delta keys (notice_key, identity_key) are byte-identical across the switch — verified against the stored baseline, 33 of 33 rows. A scheduled delta does not need resetting.

Two things genuinely changed, and both are stated on every row rather than papered over:

• site_state coverage dropped. Socrata published a dedicated job-site state column. HECC does not. The only signal is a ", XX" suffix on the published Location, present on 21 of 330 rows. A bare "Portland" is very probably Oregon — but HECC does not say so, and this actor does not guess. Those rows carry site_state: null with site_state_basis: "not_published". If you previously filtered on site_state === "OR", filter on state === "OR" (the issuing jurisdiction) instead.
• source_dataset_id now reads hecc-warn-download rather than ijbz-jpx8, because the dataset it named no longer exists.

sinceDate still works exactly as documented, but it is now applied by this actor after the fetch rather than by the source: HECC exports the whole registry in one file and offers no date predicate. The rows you get back are identical either way. | CA California | EDD WARN report (HTML/Excel) | Scaffolded — requesting it fails loudly | | NY New York | NY DOL WARN (HTML) | Scaffolded — requesting it fails loudly | | WA Washington | ESD WARN (Excel) | Scaffolded — requesting it fails loudly | | WI Wisconsin | DWD WARN (HTML) | Scaffolded — requesting it fails loudly | | IL Illinois | DCEO WARN (HTML/PDF) | Scaffolded — requesting it fails loudly | | NJ New Jersey | NJ DOL WARN (HTML) | Scaffolded — requesting it fails loudly |

Adding a state is a single config block (

{ state, format, domain, datasetId, map, requiredColumns, expectedMinRows, expectedMaxRows }

Example input — snapshot

{
  "states": ["OR", "TX"],
  "mode": "snapshot",
  "sinceDate": "2026-01-01",
  "maxResults": 100000
}

Example input — delta (scheduled monitoring)

{
  "states": ["OR", "TX"],
  "mode": "delta",
  "sinceDate": "2026-01-01",
  "priorKvKey": "warn_last_snapshot",
  "deltaStoreName": "warn-layoff-delta"
}

In delta mode with priorKvKey, the actor diffs against the snapshot stored under that key in a named, cross-run key-value store and saves the current snapshot back to it — so a daily schedule emits only what changed. (The platform's default key-value store is per-run, so a delta built on it would find an empty baseline every run and re-report the whole registry as "new". This actor uses a named store for exactly that reason.) The stored key is scoped to the states and window of the run, so two schedules with different filters cannot overwrite each other's baseline. Alternatively pass the prior records directly as priorItems.

sinceDate must be YYYY-MM-DD — anything else fails the run

sinceDate filters the notice date (and, for Texas pre-2020 and fallback reads, is spliced into a live Socrata $where clause, notice_date >= '<value>') and also keys the cross-run delta baseline. The only accepted form is YYYY-MM-DD, e.g. 2026-01-15. 2026-1-1 is accepted and zero-padded to 2026-01-01. Anything else is rejected before a single source is contacted, so the run fails and bills nothing — it is never guessed at.

Measured live against data.texas.gov/resource/8w53-c4f6 (notice_date, 2,368 rows), by sending each literal exactly as the actor would have spliced it:

Slash forms are refused rather than guessed because 05/06/2026 is genuinely ambiguous — US May 6 vs EU June 5 differ by a month, and a plausible wrong window is worse than a visible error. 2026 is refused for the same reason: it is correct today only because of how one vendor coerces text to a timestamp, not because the actor agreed to a meaning. Leaving sinceDate blank or omitting it means no date filter, which is a different thing from a filter that could not be applied.

Output fields — all 38 declared fields

The notice

The per-source outcome contract

null means not checked. false means checked and negative. These four fields exist so a buyer can never mistake an outage for an absence of layoffs.

Delta mode only

change_type (new / updated / removed), plus old_employees_affected, new_employees_affected, old_effective_date, new_effective_date, old_layoff_type, new_layoff_type. All seven are null in snapshot mode by design.

Inputs that populate the conditionally-null fields (each verified on a live run): county / region — any run including "TX". notice_id / layoff_type / layoff_type_raw — any run including "OR". site_state_matches_jurisdiction = false — {"states":["OR"]} (26 rows). layoff_type null + raw non-null — {"states":["OR"]} (16 rows). The seven delta columns — {"states":["OR"],"mode":"delta","sinceDate":"2026-04-01","priorItems":[...]}. run_states_failed / run_states_failed_reason — populate only during a genuine partial upstream failure, and source_gate_status says whether that was an outage (unavailable) or a source that answered wrongly (drift). Observed live for real: Oregon's retired Socrata dataset answered HTTP 403 on every request from ~2026-08-20 until this actor migrated to the HECC export on 2026-09-05, and throughout that period Texas rows kept flowing while every row carried run_complete: false and named Oregon as failed. industry is the one field with no populating input from the two live sources.

Live drift assertions

An offline fixture cannot see a silently degraded upstream, because the fixture was shaped from the degraded data. Before any row is fetched or billed, each live state is checked against the running service and every measured value is written to the log (DRIFT PROBE OR: {...}):

The two sources are different shapes, so they have different gates. Both are three-valued: a probe that could not complete (transport error, 5xx) is reported unavailable, which is a different finding from drift — a probe that completed and measured something wrong. Nothing is learned about drift during an outage, and this actor does not pretend otherwise. Every outcome lands in source_gate_status.

Texas (TWC workbooks): 8 probes, listed in source_probes_passed:

1. index_page: the TWC WARN page answers HTTP 200 (a bot-protection challenge is HTTP 202 and counts as unavailable).
2. year_links: every year from 2020 to last year is still linked, so a year never silently drops out.
3. xlsx_payload: every workbook answers exactly HTTP 200 with real xlsx bytes. An HTML page is never parsed as data.
4. header_contract: all 8 columns are present by name in every workbook.
5. year_consistency: each workbook holds notices from its own year.
6. date_parse: notice dates convert on every row.
7. row_floor: 1,500 to 60,000 distinct rows. The 2024 workbook repeats all of 2023, so duplicates across files are removed first.
8. positive_canary: the newest notice maps to a company and a real, non-future date.

unavailable falls back to the Socrata copy, behind the Socrata gate below. drift fails Texas.

Texas Socrata fallback / pre-2020 archive:

1. Every column the mapper reads is named in a $select. Socrata returns HTTP 400 on a renamed column, so the drift that would otherwise emit a full dataset of billable all-null rows fails the run instead. 8 columns asserted.
2. Exact row count via count(*), checked against a measured band (800–60,000 against a live 2,368). Bands are deliberately wide — a false-positive drift failure on a live actor costs real money.
3. A negative control: notice_date >= '2999-01-01' must return exactly 0. If the $where clause ever stops being applied, sinceDate is silently ignored, and this is what catches it.
4. A positive canary: the newest row must map to a non-null company and notice date.
5. Freshness: the source's own max(notice_date), reported on every row.

Oregon (HECC xlsx export) — 8 probes, listed in source_probes_passed:

1. form_page — the export form still offers WARNFormat=xlsx and WARNSort=NoticeDate.
2. report_link — the export POST returns exactly one generated WARNList_<n>.xlsx link. This is asserted on presence, never on status: HECC answers HTTP 200 either way, re-rendering the form with no link when it will not generate the report.
3. xlsx_payload — the downloaded body really is a ZIP/xlsx. HECC serves an HTML page at HTTP 200 for a report number it cannot find, and that page contains a <table>, so a spreadsheet parser will happily turn it into a workbook of parsed navigation. The magic bytes are checked before the parser is ever handed the body.
4. sheet_present — the workbook contains the WARNList sheet.
5. header_contract — the 7-column header is present in order. Columns are read by position, so a silent reorder would write the company name into city on every row.
6. row_floor — 150–20,000 data rows against a live 330.
7. source_window — the export's own "WARNs Received: … to …" line parses, so the actor can tell a buyer what period the file actually covers.
8. positive_canary — a pinned WARN number known to be in the registry is present and maps to a usable company and date. A row-count floor alone cannot tell a real export from a plausible-sized wrong one; this can.

Both: any Oregon layoff_type value outside the six live values fails the run rather than being bucketed to null.

Use from an AI agent: quickstart

The smallest input that returns a real answer. Verified live on 2026-10-05: the run SUCCEEDED and returned 5 rows in about 10 seconds.

{
  "states": [
    "TX"
  ],
  "maxResults": 5
}

Call it through the hosted MCP server (https://mcp.apify.com?tools=malonestar/warn-layoff-aggregator) or straight over HTTP:

POST https://api.apify.com/v2/acts/malonestar~warn-layoff-aggregator/run-sync-get-dataset-items
Authorization: Bearer YOUR_APIFY_TOKEN
Content-Type: application/json

with the JSON above as the body. The response is a JSON array of dataset rows.

What comes back: one row per WARN notice site. Abbreviated first row from that run (the full row has 40 fields, all described in the output schema):

{
  "state": "TX",
  "company": "JPMorgan Chase & Co.",
  "city": "Plano",
  "county": "Collin",
  "notice_date": "2026-06-23",
  "effective_date": "2026-08-21",
  "employees_affected": 244,
  "run_complete": true,
  "run_states_failed": null
}

Read before you conclude anything: run_complete, run_states_failed and source_stale_days (so "no layoffs" is never confused with an unreadable registry).

Input notes for agents

• states takes 2-letter codes. Fully wired today: OR and TX. Asking only for a state without a machine-readable source fails loudly.
• Omitting states queries every wired state and returns up to 500 rows (about $4 at the Free tier).

Cost: $0.0080 per row at the Free-tier list price (paid plans get a discount), so the example above costs about $0.040. A run that cannot answer fails and bills no rows.

Schedule a weekly feed

Run it on a schedule and receive only what changed. Delta mode keeps the previous snapshot in a named key-value store in your own Apify account (deltaStoreName, default warn-layoff-delta), scoped to the states and window you ask for. The first run records the baseline and reports every notice as new; every later run emits only new, updated and removed rows, so a week without changes costs nothing beyond the run start. If you send mode: "delta" without priorKvKey, the actor now uses the key default instead of re-reporting the whole registry every run.

Input for the scheduled run:

{
  "states": [
    "TX",
    "OR"
  ],
  "mode": "delta",
  "priorKvKey": "n8n-weekly",
  "maxResults": 1000
}

Apify Console: save this input as a task, then add a weekly Schedule to the task.

n8n (free template): we keep a ready-made workflow, growth/n8n-templates/warn-layoff-aggregator.json: a weekly Schedule trigger, an HTTP Request node calling run-sync-get-dataset-items with the input above, a Code node that counts the returned rows, and an IF node that only continues when there is at least one new row, ending in disabled Email and Slack placeholder nodes you point at your own inbox or channel. It uses core n8n nodes only (no community node) and an HTTP Header Auth credential (Authorization: Bearer YOUR_APIFY_TOKEN). Ask for it through an Issue on this page and we will send the file.

Use as an MCP tool

This actor is callable by AI agents (Claude, Cursor, etc.) via mcp.apify.com. The clean, field-level output schema makes it a good chainable tool: an agent can pull a state's WARN notices, filter by company, county or headcount, and hand rows to an outreach, enrichment or analysis step. The run_complete / run_states_failed fields let an agent tell a genuine "no layoffs" from an unavailable registry without reading logs.

Pricing

Pay per result — one WARN notice (or one delta change row) = one dataset item. Graduated discounts apply on paid Apify plans. A run that fails because every source was unavailable emits nothing and bills no result events.

Was this useful?

If a run answered your question, a short review on this Store page helps other buyers find the Actor; every published review is read. If a run gave a wrong or confusing answer, open an Issue on this page with the run ID and it will be treated as a defect, not feedback.

FAQ

How do I monitor for new layoff notices? Run in delta mode on a schedule with a priorKvKey; each run emits only new / updated / removed rows. The first run establishes the baseline and reports everything as new — the log says so explicitly.

Which states are live today? Oregon and Texas. Texas is the Texas Workforce Commission's keyless yearly xlsx workbooks (Socrata copy as fallback); Oregon is the keyless, login-free HECC Rapid Response xlsx export. California, New York, Washington, Wisconsin, Illinois and New Jersey are scaffolded config blocks; requesting only those fails the run with a message naming the live states, rather than returning an empty dataset.

What counts as an "updated" notice? The employee count, effective date, notice date, or layoff type changed versus the prior snapshot — for the same job site. A revision to a region label or the run timestamp is not a change.

Why does an Oregon row sometimes show a city outside Oregon? Because Oregon's registry contains them. state is the issuing registry; site_state is where the job site actually is where HECC publishes it — a ", XX" suffix on the location, 21 of 330 live rows — and site_state_matches_jurisdiction flags those as false. On the other 309 rows HECC publishes no state at all, so both fields are null rather than a guessed "OR"; site_state_basis tells the two cases apart.

Oregon's newest notice looks old — is the actor broken? No: source_last_notice_date and source_stale_days report the state of the source itself, not of this actor. On 2026-09-05 Oregon's newest notice was 2026-09-01, four days old. If that number grows, the state has stopped publishing — and every row tells you so rather than letting the gap read as "no layoffs".

Oregon used to come from Socrata — did my rows change? The source changed in September 2026; the rows did not. See "Oregon changed source in September 2026" above for the two fields that genuinely differ (site_state coverage and source_dataset_id) and for why a scheduled delta needs no reset.

Texas used to come from Socrata. Do I need to reset my delta? No. See "Texas changed source in October 2026" above. Keys are unchanged. The first delta run after the switch reports the notices TWC has published since July as new, which is correct, and reports the handful of TWC corrections as updated.

Do I need an API key? No. All sources are public and keyless.

How is it billed? Pay per result — one WARN notice (or one delta change row) = one dataset item.

Related actors

Other feeds from the same catalogue for recruiters, RevOps and market researchers. The Where both cover column lists only the places both actors actually serve (see each actor's own Coverage table).

Telemetry

This actor can send one usage record per run to the publisher: the channel the run was started from (Console, API, MCP, scheduler, ...), a timestamp, the build number, a salted one-way hash of the account id (so repeat use can be counted without storing the id itself), and the NAMES of the input fields used. It never records input values, results or the account id, and it is used only to see how buyers reach the actor. It cannot slow the run by more than 3 seconds and can never affect your results or your bill.