Define one alert question
Begin with one role family and one market, such as newly posted cybersecurity jobs in London or new sales-leadership jobs at a named company. Broad queries produce repeated cards and make it difficult to tell whether a change is meaningful.
Run the LinkedIn Jobs Search Scraper once with a small cap:
{
"queries": ["cybersecurity engineer"],
"locations": ["London"],
"includeDescriptions": true,
"maxResultsPerQuery": 50
}Inspect job IDs, source URLs, posting dates, and descriptions. Save the reviewed input as an Actor Task only after it returns the intended market.
Create a baseline before sending alerts
The first successful dataset is a baseline, not a list of new jobs. Store each stable jobId with its source URL, first-seen time, disclosed posting date, and a hash of fields you plan to monitor. Sending every baseline row creates a burst of false “new” alerts.
| State | Alert? | Reason |
|---|---|---|
| ID appears in the first complete run | No | Baseline only. |
| Unseen ID with a disclosed posting date after the last successful check | Yes | Supported new-job event. |
| Unseen ID with no date or an older date | Review | It may have surfaced because ranking or pagination changed. |
| Known ID with no tracked-field change | No | Unchanged repeat. |
| Known ID disappears from one result page | No | Absence is not proof of removal. |
Schedule the saved Task
In Apify Console, create a schedule only after the Task has passed a manual run. Choose a timezone and interval that match the buyer need. Hourly checks are rarely justified for broad labor-market research; daily checks are easier to audit and cost less. Apify schedules support timezone settings and daylight-saving changes.
Review the official Actor and Task schedules guide before relying on exact timing. Scheduled starts can be delayed by platform load, so compare against the previous completed check timestamp rather than assuming a perfect clock boundary.
Compare complete snapshots safely
- Accept a snapshot only when the run succeeds and expected query segments are present.
- Normalize stable IDs before comparison.
- Commit the new state after output and downstream storage succeed.
- Keep same-day ambiguous cards out of automatic “new” alerts.
- Compare changed fields only for IDs present in both snapshots.
- Require direct description evidence for benefits, sponsorship, seniority, or remote-work claims.
A blocked page, partial fetch, empty result caused by an error, or timed-out run must not replace the last good baseline. Otherwise the next healthy run will look like a market surge.
Send idempotent webhook alerts
Apify webhooks can send an HTTP POST when a run succeeds or fails. The receiving endpoint should return quickly, authenticate the request, enqueue longer work, and deduplicate using the webhook dispatch or run ID. Apify notes that webhook delivery can occasionally happen more than once.
Use ACTOR.RUN.SUCCEEDED to begin snapshot comparison and a failure event to notify an operator. Do not send business alerts directly from a run-success event before validating the dataset. See the official webhook guide and event reference.
Failure and cost checklist
- Keep the previous good state after failed, aborted, or timed-out runs.
- Alert an operator after repeated infrastructure failures, not job-market users.
- Cap each query and location combination.
- Track rows retrieved, rows accepted, and meaningful alerts separately.
- Check the Actor's live Pricing tab before increasing frequency.
- Do not call owner test runs external usage or demand.
Need a narrower hiring segment?
Compare salary, remote, internship, executive, sponsorship, contract, and company workflows before building the monitor logic yourself.
Compare LinkedIn tools