Build a WARN tracker without maintaining a scraper per state
State layoff notices arrive as spreadsheets, PDFs, tables and dashboards. Let AyeWatch watch the pages and send new filings to your webhook or Slack.
By ClaudeGPT Si Newsroom, Editorial team
3 min read
A WARN tracker is a watch on the state pages where layoff and closing notices get posted, and the hard part is not sending the alert but reading the inputs, because every state publishes them differently. For most developers the practical build is to let AyeWatch watch those pages, send new notices to a webhook, and keep your own code for whatever happens next.
The data you are tracking
Federal rules require a covered employer to give 60 days of written notice before a qualifying plant closing or mass layoff, and one copy goes to the state's dislocated worker unit (20 CFR 639). States then post what they receive. The fields worth storing are fairly stable: employer, site address, county, number of affected workers, notice date, effective date, and whether the action is a layoff or a closure, permanent or temporary.
The inputs are the unstable part.
Why per-state scrapers break
| Source | What you get | What tends to break |
|---|---|---|
| California EDD | A current spreadsheet plus yearly PDFs | The file is replaced, so you diff rows yourself |
| New York DOL | A dashboard with filters and downloads | It is built for clicking, not parsing |
| Washington ESD | An HTML table sorted by received date | Columns and paging change |
| New Jersey DOL | One PDF per year that keeps growing | PDF parsing and duplicate rows |
| Illinois workNet | A new spreadsheet each month | A new file to find every month |
That is five parsers for five states, and each fails quietly when a state redesigns its site or its forms. Requirements move too: California added new required content to its notices in 2026.
A lighter build
1. One monitor per state page. In AyeWatch, add each state's WARN page as a webpage monitor. You get told when a meaningful detail changes, with a summary, instead of a raw HTML diff.
2. Filter in plain English. Write the rule the way you would explain it to a teammate: "Alert me when a notice names any of these twelve employers." Changes that do not match stay out of the feed.
3. Add a topic monitor for coverage. A second monitor can look across news and public pages for new WARN filings that name the same companies. Local reporters often write these up quickly, and that covers states you have not added as pages.
4. Send it to your code. Paid plans add webhooks and a REST API for creating, listing, updating and deleting topics, and the webhook events are signed. There is also an MCP server, so an agent can create or pause monitors from a chat.
5. Keep your own history. Your webhook handler writes the summary and source link into your table, Slack channel or ticket queue. The tracker now has a record in your format, and you never wrote a PDF parser.
6. Keep the record small. Per alert, store the employer, the state, the source link and the time you saw it. Headcount and effective date live in the notice itself, so link to it rather than copying numbers that a revised notice may later change. Start with one state for a week before you add the rest.
When to write the scraper anyway
If you need every row from every state, for a research dataset or a chart of counts over time, you need structured data, and a scraper or a bought dataset is the right tool. Before you build one, look at aggregators: WARNTracker.com already collects public WARN records into a searchable database by state, year and company, with email alerts and a paid data subscription.
If the job is "tell me when one of these companies files," AyeWatch is the shorter path. It is not a WARN database, and it only covers the pages and topics you set up. There is a free preview, and the paid plans that include webhooks and the API start at $9 a month (pricing).