APProjects/us-warn-act-layoffs-point-in-time-snapshots

US WARN Act layoff notices — point-in-time (as-of) snapshot archive

25 daily vintages, 2026-08-30 → 2026-09-24. 1,067,077 total rows, 42 MB compressed. One new vintage every day, forever.

This is the same US WARN Act layoff dataset as the daily mirror — except you can load it as it stood on a past date, instead of only as it stands today.

from datasets import load_dataset

# the table exactly as it was published on 5 September 2026
past = load_dataset("APProjects/us-warn-act-layoffs-point-in-time-snapshots", "asof-2026-09-05", split="train")

# today's table
now  = load_dataset("APProjects/us-warn-act-layoffs-point-in-time-snapshots", "latest", split="train")

Why you would want a past vintage

WARN data is not append-only. State agencies amend headcounts, re-issue notices under new numbers, and silently delete rows. Across the 25 builds in this archive we have observed 2,056 amendments and 426 rows that stopped appearing, touching 2,209 distinct notices (the itemised diff is its own dataset: notice changes).

So if you backtest a layoff signal against today's file, you are trading on information that did not exist on your trade date, against a universe that has had its failures quietly tidied up. That is look-ahead bias plus survivorship bias in the same file. Loading the vintage for your as-of date removes both.

The same applies outside finance: if you published a figure in a paper or a report last month and the number moved, this archive is how you show which file you actually used.

Nobody can backfill this. Anyone can re-scrape 48 state portals this week and reproduce today's table. Nobody can reconstruct what those portals said on 2026-08-30 — those pages are gone. An archive that starts tomorrow starts empty and stays a day behind this one forever.

Read this before you use it — three honest limits

1. 1.*A snapshot is what our pipeline published that day. It is not a certified record of what a state agency's website displayed that day.* If our scraper was broken, slow, or had not yet reached a state, the vintage reflects that.
2. 2.Row-count growth in the earliest vintages is largely our own coverage expanding, not the labour market. The pipeline added states during this window; the biggest single day-over-day row-count swing we recorded was 397% (2026-09-06 → 2026-09-07), and it was a coverage change, not a wave of layoffs. Look at the per-day row counts in the table below and in manifest.csv before you difference two early vintages and call it economics. Row counts have been stable to within 1% a day since `2026-09-13` — if you need a clean differencing window, start there.
3. 3.*The archive starts 2026-08-30. The notices go back to 1988; the snapshots do not.* A day with no commit has no vintage — manifest.csv lists exactly the days that exist, and there may be gaps.

The first-appearance index — the small file you probably want

You do not need to download every vintage to backtest honestly. first_appearance.csv has one row per notice id that has ever been in any vintage (61,922 ids) with the first and last vintage it appeared in. Join it to today's table on id and drop every row whose first_vintage is after your trade date — that is the whole look-ahead fix in one line. in_latest = false (491 ids) is the survivorship fix: notices that were published and have since disappeared from the live table, which today's file cannot show you at all. (This is a larger count than the 426 "rows that stopped appearing" in the itemised change log because the change log deliberately skips day-pairs where our coverage window moved; the index counts every id, whatever day it vanished.)

idx = load_dataset("APProjects/us-warn-act-layoffs-point-in-time-snapshots", "first-appearance-index", split="train").to_pandas()
knowable = idx[idx.first_vintage <= "2026-09-05"]   # what existed on your as-of date

Why not just use the main table's `first_seen` column? Because for rows our pipeline backfilled from an agency's historical archive, first_seen is set to the notice's own date, not the day we first saw it. It is a display field, not an observation time. first_vintage here is mechanical: it is the first published file that contained the id.

`appearance_class` tells you which rows measure anything. Only contemporary rows (stated date within 60 days of first appearance, on a day our coverage window did not move) say something about how long after a notice is dated it becomes publicly visible. The rest are about us, not the agencies:

For the 125 contemporary notices that first appeared after 2026-09-10 (the last day our own coverage window moved), the gap between a notice's stated notice_date and the day it entered this dataset was: median 5 days, 75th percentile 6, 90th percentile 15; 18% entered more than 7 days after their stated date and 4% more than 30 days after. That gap is agency publishing delay plus our fetch cadence; we cannot separate the two, and with n=125 these are early numbers — they tighten every day as the file grows.

Files

sha256_uncompressed is the checksum of the decompressed CSV, so you can quote a vintage in a paper and let a reader verify byte-for-byte that they loaded the same file. source_commit is the commit in the public repo the bytes came from, so the provenance is independently checkable: https://github.com/APVentureEngine/warn-act-notices.

The vintages

Schema

Identical to the daily mirror — employer, location, workers affected, notice date, effective date, state, notice type, canonicalized employer name, stable notice id. See that card for the per-column description.

Licence and provenance

CC BY 4.0, like every dataset in this family. Underlying records are US state public records published under the Worker Adjustment and Retraining Notification Act. Built and republished daily by an automated pipeline; the free current-day table, per-state feeds and the full change log are at https://approjects-warn-act-notices.static.hf.space.

Related: daily mirror · observed change log · source repo

<!-- warn-feed:offer:start -->

A layoff record you can audit, not just download

This dataset is one cut of a single daily rebuild: 61,431 US WARN Act layoff notices from 48 state agencies, 1988 to today, one schema, no login, no delay, CC BY 4.0. Snapshot as of 2026-09-25; the files above are rebuilt every day, so the live count is the truth.

Several projects publish a current WARN scrape and two of them carry more rows than we do. None of them publish what the records used to say:

• —2,482 observed changes to already-published notices, logged daily since 2026-08-31. data/revisions.csv records every field that differed between two consecutive daily builds — employee counts, effective dates, notice types, company names — with the old value, the new value and the date we saw it. We publish the observation and not the cause: a change is equally explained by the agency amending the notice or by our own parser improving, and we do not guess which (see data/revisions.README.txt). A scrape that starts tomorrow cannot backfill any of it; it only exists if someone was watching.
• —6,799 notices whose state agency page no longer lists them. Agencies take notices down. We keep them, flagged as archive-only, so a count you ran last year still reconciles.
• —Point-in-time employer identity. The ticker crosswalk resolves a filer to the company as it existed at the time of the notice — Kmart, Sears Holdings, Symantec — not to whatever is on today's ticker file.

If you have to defend a number to an editor, a referee or a compliance reviewer, that provenance layer is the part you cannot rebuild yourself. How to cite this dataset →

Look something up right now — free, no signup, nothing to install. Check any employer or state against the last 180 days → It runs in your browser against these same files.

Building something with it? The same files are a free HTTP API — JSON and CSV, no key, no signup, access-control-allow-origin: * so fetch() works from a browser: endpoints, schema and curl examples →

Prefer a spreadsheet? One formula puts the last 90 days, the last 12 months or any single state into Google Sheets as a live range that refreshes itself — no signup, no add-on: the formulas, one per state → =IMPORTDATA("https://cdn.jsdelivr.net/gh/APVentureEngine/warn-act-notices@main/data/sheets/us-last-90-days.csv")

Backtesting, or citing a figure you published last month? Today's file has look-ahead and survivorship bias baked in: notices get amended after the fact and some rows are later deleted. The same table as it stood on any past day since 2026-08-30 — one immutable vintage per day, 25 so far, plus a first-appearance index giving the first and last day every notice id was in the file — is the point-in-time snapshot archive. Nobody can backfill it.

Need one industry only? The same filings, cut by an auditable employer-name rule (each row keeps the rule that fired): tech companies · hospitals & healthcare · retail store closings · restaurants & hotels · factory & plant closings · banks, insurance & finance · warehouses, trucking & logistics · all 20 sectors.

Need it shaped differently? The vintages, the change log and the ticker mapping are all free and rebuilt daily, but a bias-free panel is usually a join someone has to write: vintages against the public-company ticker mapping, a single as-of reconstruction for a fixed date range, a first-reported/amended/ deleted event table, or a coverage question for a specific state and period. That join is what we do as paid work, quoted per request rather than listed at a price, because every ask so far has had a different shape. Say what the panel needs to look like and what you would use it for: open an issue — it is read, and a quote comes back with the method written out.

Two things worth stating plainly before you ask. A snapshot is what this pipeline published that day, not a certified record of what the agency's site displayed. And the vintages begin at the archive's first snapshot, not 1988 — the NOTICES go back to 1988, the SNAPSHOTS do not, and no payment changes that.

Tracking named employers rather than backtesting? WARN Watch — $49 for a year, one payment, no auto-renew, 14-day refund: up to 500 employer names plus whole states matched on every daily refresh, to a private alert page + .ics + RSS + optional Slack / Discord / Teams webhook. See a real alert page · try it free for 30 days, no card

Not deciding today? Join the update list → — one email when a new dataset or tier is published; nothing promotional. A state added or a column renamed ships in the daily release instead, no address needed. The list is shared across APProjects datasets, holds an email address only, is run by Gumroad, and any message unsubscribes you. Rather give no address at all? Watch the repo's releases — GitHub notifies you on every daily republish, and a new state or changed field is in those notes the day it lands.

Reaching a human. WARN Feed is published by APProjects, an automated data publisher — that is stated plainly rather than dressed up. Corrections, coverage gaps, schema questions and refund requests all go here and are read: open an issue. Payments are handled by Gumroad as merchant of record, so an invoice can carry your company name.

Source, scrapers and methodology · the 48-state site <!-- warn-feed:offer:end -->

<!-- warn-feed:px:start --> <img src="https://cdn.jsdelivr.net/gh/APVentureEngine/warn-act-notices@main/assets/px/hf/us-warn-act-layoffs-point-in-time-snapshots.png" width="1" height="1" alt=""> _{Card views are counted anonymously: one 1×1 image on a public CDN, no cookies, no script, no personal data. The count is public: <a href="https://data.jsdelivr.com/v1/stats/packages/gh/APVentureEngine/warn-act-notices@main/files?period=month">jsDelivr stats</a>.} <!-- warn-feed:px:end -->