Define the monitoring question
Choose a narrow question before scheduling anything: new Python jobs worldwide, engineering roles above a salary floor, companies mentioning async work, or the newest design roles. A focused input produces a dataset that is easier to compare over time.
Use tag for the role or skill, location for geographic language, benefits for terms such as async or equity, and minimumSalary when only jobs with a qualifying annual USD range should remain.
Use the public feed path efficiently
The current actor reads RemoteOK's public JSON feed and normalizes the results instead of driving a browser. That reduces page-rendering overhead and makes the workflow suitable for recurring monitoring.
The actor still applies its own filtering, sorting, normalization, result limits, and no-match diagnostics before rows are written to the Apify dataset.
Create a stable deduplication key
Use remoteOkId as the primary source identifier and keep jobLink as a reviewable source URL. For historical monitoring, add the Apify run start time or your ingestion timestamp rather than overwriting the first observation of a job.
A daily snapshot can then distinguish newly observed jobs, persistent listings, salary changes, and removed listings without relying only on a job title and company name.
Schedule and deliver the result
After the test run returns the expected rows, save the input as an Apify Task. Schedule it at the cadence your team can actually review; daily is useful for alerts, while weekly is often enough for market research.
Use a webhook or downstream automation to read the completed dataset, deduplicate remoteOkId values, and send only new matches to the destination.
Handle empty matches correctly
When no jobs match the filters, the actor writes a diagnostic item containing the selected filters. Treat that as a valid no-match result, not as a new job and not automatically as a source failure.