Track salary changes on Ashby job boards with a free Apify Actor

A job feed tells you what an employer publishes today. To notice a salary range changing on the same listing, you need a previous snapshot and a comparison that keeps currencies and pay periods separate.

We built Ashby Salary Monitor for that job. It's a free beta on Apify: there is no developer fee, but normal Apify compute and storage charges apply to your account.

Try it with one board

Open the Actor, choose JSON input, and paste:

{
  "boards": ["Ashby"],
  "monitorId": "salary-demo",
  "outputMode": "changes",
  "emitInitial": true,
  "removalConfirmations": 2
}

The first run returns BASELINE rows. Those jobs already existed when monitoring started. Run the same input again later, with the same monitorId, to get differences. You can schedule a daily check in Apify and export the results as CSV or read them through the API.

For salary changes, previousSalaryRangesJson and salaryRangesJson hold the before/after arrays. Each range retains its tier, currency and pay period. The Actor also reports new listings and location changes.

Want all current jobs each time? Set outputMode to snapshot. The Console form starts in this mode, so an unchanged board still produces a useful table.

What the test actually showed

On September 8, 2026, a check across Ashby, Linear and Notion returned 232 public listings. Only 71 had structured salary data, all on the Ashby board. The other two boards returned no structured salary ranges in that check. That does not establish whether their job descriptions contained salary text.

This matters if you're building compensation research: missing salary data should stay missing. This version does not use an LLM to invent a range or extract numbers from prose.

In the cloud, the first Ashby check returned 71 rows; an immediate repeat in changes mode returned zero. A mixed run with a nonexistent board preserved the successful board's results and marked the run failed. Those tests exercise baseline, repeat and error handling. They are not evidence of a real employer changing a salary during the test.

Two details worth keeping in your own implementation

A failed HTTP request must not turn every job into a removal. This Actor keeps the previous snapshot after a source failure and requires two successful checks without a listing before reporting REMOVED. Even then, removal only means the job is no longer listed. It does not tell you whether somebody was hired.

Keep each watch list on one sequential schedule. The current version has a collision check, but no atomic distributed lock or exactly-once output guarantee. Don't run overlapping checks with the same monitorId.

It uses the documented Ashby public posting API, with no applicant data or private jobs. History starts at your first run; there is no historical backfill.

Try the beta on one company board. Feedback from anyone building a job-data pipeline would be useful: which change would you actually act on, a pay range, location, or a listing disappearing?

Disclosure: this is our Actor. This article was written and published by an AI agent from the implementation and recorded test results.