Pricing

from $8.50 / 1,000 change founds

Hiring Trend Monitor by Job Function

Track comparable public hiring slices over time. Get explicit baselines, before/after function counts, materiality, confidence, source gaps, and review actions without fabricating growth on the first run.

Pricing

from $8.50 / 1,000 change founds

Rating

0.0

(0)

Developer

Tim Zinin

Actor stats

Bookmarked

Total users

Monthly active users

a day ago

Last modified

Hiring Trend Index

Watch which job functions — engineering, sales, marketing, product, and 8 more — a company or a whole job market is hiring for, and get told what changed since your last check. Not a one-off count: a real trend, backed by your own history of checks.

What you get

Each run checks a small list of slices you choose and reports, per slice:

First check ever for that slice — a baseline snapshot: how many open roles right now, broken down by function. This is billed once, the same as any other result — it's a real, useful snapshot, not filler.
Every check after that — what changed since the last one: total open roles delta, and a per-function breakdown (growing / shrinking / flat, with the exact before/after counts).

A single run can never know "growth" on its own — that needs two points in time. This Actor is honest about that: it never reports a trend on a slice's first-ever check, only a snapshot labeled as such.

How to run it

Click Try for free — no card needed on the free plan.
In Slices to watch, add one entry per company, format company:<ats-provider>:<token> (e.g. company:greenhouse:gitlab) — or just company:<token> (e.g. company:stripe) and this Actor auto-detects the ATS provider for you.
Optionally set a Watch name (watch_key) if you're running more than one independent set of watches from the same Actor.
Hit Start. The first run for each slice creates a baseline (billed the same as any other result); every run after that compares against it and reports what changed, pulled from the dataset (UI, API or webhook).

Slices

Two kinds, as strings in the slices input:

company:<ats-provider>:<token> — a company's own public job board (Greenhouse, Lever, or Ashby), e.g. company:greenhouse:gitlab, company:ashby:ramp. You can also drop the provider (company:stripe) and the built-in adapter will auto-detect it.
board:<name>[:<keyword>] — a sample from jobs.ch, Jobs.ge, XING Jobs or Boss.az (a whole country/market's currently open roles, not one company).

Default (and what the daily platform test runs): two well-known, already-verified company boards (GitLab and Stripe, both on Greenhouse).

What's live today

Both company:* and board:* slices use source adapters embedded in this Actor. There is no child Actor run, buyer-token hand-off, or second Actor charge. Supported boards are jobs-ch-swiss, jobs-ge, xing-jobs, and boss-az; jobs.ch and Jobs.ge require a keyword.

Partial results

If one of your slices doesn't respond this run (a timeout, a typo in the slice string, a sitemap/detail failure, or the buyer's charge limit running out mid-run), the OTHER slices still deliver normally. You'll additionally get one free summary row with partial: true, missingSlices, and source counters naming exactly which slice(s) were incomplete and why. An incomplete slice never advances its baseline.

Watching several independent trends

Use watch_key to run more than one independent set of watches from the same Actor (e.g. "competitor-tracking" vs "my-own-hiring") without one run's memory overwriting another's.

Pricing

Pay-per-event. The Actor accepts only Apify's exact six-tier contract: FREE $0.005/$0.010, BRONZE $0.00475/$0.0095, SILVER $0.0045/$0.009, GOLD $0.00425/$0.0085, PLATINUM $0.0041/$0.0082, or DIAMOND $0.004/$0.008 per run start/result. A result is a complete slice snapshot (including a safely confirmed fresh baseline). Empty/not-found, partial, and error rows are free. A malformed pricing contract, exhausted budget, or unconfirmed charge fails closed and never advances the affected baseline.

Input

Field	Required	What it does
`slices`	yes	1-10 entries, one per company/board to track. `company:<ats-provider>:<token>` (provider optional, auto-detected) or `board:<name>[:<keyword>]`.
`watch_key`	no	Name for this set of watches, so several independent watches from the same Actor don't overwrite each other's memory. Default `apify-daily-test` — replace it with your own.
`new_window_days`	no	Company slices only: how many days back a posting still counts as "new" in the underlying signal. Default 30.

{
    "slices": ["company:greenhouse:gitlab", "company:greenhouse:stripe"],
    "watch_key": "my-watch"
}

Output

Real row from a live platform run (2026-07-30), company:greenhouse:gitlab checked a second time — baseline already existed, so this is a trend comparison, not a first-check snapshot:

{
    "slice": "company:greenhouse:gitlab",
    "sliceKind": "company",
    "token": "greenhouse:gitlab",
    "source": "greenhouse",
    "found": true,
    "baselineCreated": false,
    "totalOpenRoles": 183,
    "totalOpenRolesBaseline": 183,
    "totalOpenRolesDelta": 0,
    "trend": {
        "engineering": { "baseline": 55, "current": 55, "delta": 0, "direction": "flat" },
        "sales": { "baseline": 34, "current": 34, "delta": 0, "direction": "flat" },
        "support": { "baseline": 30, "current": 30, "delta": 0, "direction": "flat" },
        "other": { "baseline": 21, "current": 21, "delta": 0, "direction": "flat" }
    },
    "byFunction": {
        "engineering": 55,
        "sales": 34,
        "support": 30,
        "other": 21
    },
    "partial": false,
    "missingSlices": [],
    "checkedAt": "2026-07-30T11:28:31.999Z",
    "error": "",
    "summary": "\"company:greenhouse:gitlab\": 183 open role(s) now (+0 since last check)."
}

Field	Meaning
`found`	`true` when the slice resolved to a real board; `false` for a not-found slice (see below).
`baselineCreated`	`true` only on a slice's first-ever check for this `watch_key` — every later check is `false`.
`totalOpenRoles` / `totalOpenRolesDelta`	Current open-role count and the change since the last check (`0` for a first check's own baseline).
`trend`	Per-function breakdown: `baseline`/`current` counts, `delta`, and `direction` (`growing` / `shrinking` / `flat`). Trimmed here to 4 functions; up to 12 come back in a real run.
`byFunction`	Current open-role count per function, flat (no history).
`partial` / `partialReason` / `missingSlices` / `sourceStats`	See "Partial results" above. These fields preserve board sitemap/detail failure and cap evidence instead of presenting an incomplete scan as complete.

A not-found slice (verified live, 2026-07-30 — no such company on any supported ATS) looks like this and is never charged:

{
    "slice": "company:greenhouse:zzznonexistentcompany123456xyz",
    "sliceKind": "company",
    "token": "greenhouse:zzznonexistentcompany123456xyz",
    "source": null,
    "found": false,
    "baselineCreated": false,
    "totalOpenRoles": null,
    "trend": null,
    "byFunction": null,
    "partial": false,
    "missingSlices": [],
    "checkedAt": "2026-07-30T11:28:39.692Z",
    "error": "",
    "summary": "No public job board found on greenhouse for \"zzznonexistentcompany123456xyz\". Check the ATS token (e.g. \"greenhouse:stripe\")."
}

Other tools we built

Related tools for adjacent workflows in B2B lead generation and data enrichment, jobs and hiring.

Actor	What it does
Company Hiring Radar	Pair it in the jobs and hiring workflow: Pull every open role a company is hiring for from its public job board (Greenhouse, Lever, Ashby) and turn...
Jobs.ge Georgia Jobs Scraper	Pair it in the jobs and hiring workflow: Search Jobs.ge (Georgia, the country's oldest job board) and get public job listings: title, employer,...
Tech Stack Change Detector	Pair it in the B2B lead generation and data enrichment workflow: Detect a website's current technologies (CMS, ecommerce, analytics, marketing/CRM, framework, hosting/CDN,...
Computrabajo LatAm Jobs Scraper	Pair it in the jobs and hiring workflow: Search Computrabajo (Mexico, Colombia, Chile, Argentina, Peru) by keyword and get public job listings:...
Job Postings Aggregator	Pair it in the jobs and hiring workflow: Pull every open role from a company's public applicant-tracking system (Greenhouse, Lever, Ashby) and...

FAQ / Limitations

Does the first check for a slice tell me anything useful? Yes — it's a real, billed snapshot of open roles right now, per function. It's just never labeled as a "trend", because a trend needs a prior check to compare against.

Greenhouse, Lever, and Ashby responses are validated as provider-specific job envelopes with HTTPS job identities. Schema drift is a source error, not a silent empty board. A present but malformed stored baseline is likewise fatal and is never replaced as though the slice were new.

What this is NOT. This is not an applicant-tracking or job-application tool. It reads public Greenhouse/Lever/Ashby boards and supported public job markets through adapters embedded in this Actor; it does not submit applications or access private employer data.

Found a bug or need a custom variant (a different ATS, a market-wide board once one of this factory's job-board Actors ships)? Open an issue on the Actor page.

Commercial guide: Hiring Trend Index — Stateful Function-Level Change Monitor

Track comparable public hiring slices over time and receive explicit baselines, before/after counts, function changes, materiality, confidence, and retry-safe advisories.

This guide is written for buyers, operators, analysts, and automation builders. It explains what the Actor observes, how to turn the Dataset into a controlled workflow, and where human verification remains mandatory.

The decision this product supports

What materially changed in the same supported hiring slice since the previous valid observation, and how reliable is that comparison?

The Actor reduces collection and first-pass triage work. It does not remove responsibility for source verification or authorize an external business action. The commercial value comes from a structured, repeatable evidence layer: stable identity, observation time, source evidence, confidence, gaps, recommended action, and failure semantics travel with the raw facts.

Who uses it

User	Value
B2B marketers	Review verified hiring expansion or contraction as one contextual account signal.
Founder-led sales teams	Watch a small strategic account set without manually comparing job-board counts.
Competitive intelligence teams	Track function mix changes with explicit before/after evidence.
Recruiting analysts	Observe public role-count movement across supported company boards or market slices.
RevOps teams	Send material, high-confidence events into an analyst queue while keeping first runs and failures out.
Automation builders	Use eventId, baseline semantics, change flags, materiality, and source failure handling.

Input contract

Input field	How to use it
slices	Required list of 1–10 company or supported board slice identifiers. The exact slice string defines the observed entity.
watch_key	State namespace for this watch set. Reuse it for comparisons; use a different key for an independent baseline.
new_window_days	Company-slice lookback used by the underlying current-role signal. It does not affect board slices.

Recommended first Input

{
  "slices": [
    "company:greenhouse:gitlab",
    "company:greenhouse:stripe"
  ],
  "watch_key": "my-hiring-watch",
  "new_window_days": 30
}

Start with this bounded example, inspect every Dataset field, and only then expand the scope. Input limits are product controls, not inconveniences: they make cost, completeness, and error handling visible.

Field dictionary

Field or group	Meaning
entityId, eventId, slice, inputRef	Stable watched slice and observation-event identity.
firstSeenAt, previousObservedAt, lastSeenAt, observedAt	Baseline and current observation boundaries.
before, after, totalOpenRolesDelta, changeMagnitude	Comparable total and function-level state before and after.
trend, byFunction, growingFunctions, shrinkingFunctions	Normalized function mix and observed directions.
changeFlags, materialityScore, materialityBand, materialityReasons	Deterministic change classification separate from evidence confidence.
baselineCreated	True on first observation; no prior trend is fabricated.
partial, missingSlices, sourceEvidence	Coverage and current normalized source counts.
confidenceScore, confidenceBand, confidenceRisks	Support for the comparison after baseline, source, and partial checks.
recommendedAction, actionPriority, safeToAutomate	Human-review routing for expansion, contraction, flat, first, and failed observations.
failureType, retryable, recommendation	Handling for partial source, baseline error, budget, source failure, or unresolved slice.

Common decision fields

Field	Operational meaning
recordType	The semantic row family. Use it to distinguish a business result from an advisory or terminal record.
schemaVersion	Version of the additive decision-intelligence contract. Pin or validate it in strict consumers.
entityId	Stable entity identity for deduplication and joins. It is not necessarily a legal identifier.
inputRef	The relevant submitted input reference after normalization.
observedAt	When the Actor observed or finalized the evidence. It is not necessarily the source publication time.
firstSeenAt and lastSeenAt	Always-emitted observation boundaries. Stateful monitors use the compatible baseline/current boundary. Stateless rows set both equal to observedAt for the current run; that equality does not establish historical tenure.
freshness	A structured statement about evidence age or availability, not a prediction. Its basis and age unit follow the source-specific field definition.
eventId	For monitors, the stable identity of one observed transition or monitor outcome. It is distinct from entityId.
before and after	For monitors, the bounded comparable snapshots used for the decision. Null means that side of a comparison was not honestly available.
changedFields and changeFlags	Machine-readable monitor deltas and normalized change labels. Empty arrays mean no supported changed field was established, not that every possible real-world fact stayed constant.
materialityScore and materialityBand	Magnitude of an observed monitor change when the Actor can calculate it. Materiality is separate from evidence confidence and may be unknown when the source lacks the required facts.
confidenceScore	Evidence support on a 0–100 scale. It is separate from materiality, lead score, or business value.
confidenceBand	Readable high/medium/low/unknown grouping of evidence support.
confidenceReasons	Observed facts that raise confidence.
confidenceRisks	Missing, partial, ambiguous, inferred, or conflicting aspects that reduce confidence.
confidenceConflict	Explicit consistency warning when structured evidence does not reconcile.
sourceEvidence	Source-linked observations supporting the row. Preserve this during export.
dataGaps	Important evidence the Actor did not observe or cannot establish. Keep these gaps visible in CRM, spreadsheet, and automation exports.
negativeSignals	Machine-readable risks or gaps. A negative signal is not automatically a negative business outcome.
recommendedAction	Bounded review label produced from the available evidence.
actionPriority	Suggested queue priority, not urgency guaranteed by the source.
actionReason	Plain-language explanation for the recommended action.
safeToAutomate	Whether the narrow recommended action is deterministic enough for automation. Organizational policy still applies.
failureType	Normalized terminal or partial failure classification. Null means no classified failure.
retryable	Whether a later retry may legitimately change an operationally incomplete result.
recommendation	Human-readable handling guidance, especially for terminal rows.

Evidence, confidence, and honest boundaries

What the evidence supports

The first successful observation creates a baseline and never claims a trend.
A change compares the same normalized slice/function taxonomy against the prior valid state in the same watch namespace.
Materiality measures observed count movement; confidence measures support for that comparison.
Partial or failed slices cannot produce a trustworthy aggregate movement claim.
A confirmed charge and valid delivery are required before affected state advances under the runtime contract.

What this Actor never claims

The Actor does not infer buyer intent, revenue growth, layoffs, budget, strategy, or financial health from hiring counts.
It does not treat the initial baseline as an increase from zero.
It does not compare different watch keys or materially different slice definitions as one continuous history.
It does not turn a source failure into contraction or zero hiring.
It does not claim that every listed opening will be filled or remains open after observation time.

Reading data gaps correctly

A data gap is part of the result. Nulls, partial flags, confidence risks, source failures, and unavailable fields must survive export. Removing these fields makes the remaining facts look more complete than they are. When two sources conflict or a required identity cannot be proven, lower confidence and keep safeToAutomate=false.

Source evidence is not permission

A public source proves only that a value or statement was observable at the recorded time and URL. It does not establish consent, contractual rights, legal status, accuracy after observation, or authorization for a downstream action. Your organization remains responsible for source terms, privacy rules, outreach policy, retention, and human review.

Decision policy and action routing

Action	How to use it
SCHEDULE_NEXT_COMPARISON	Keep the same watch key and slice definition so the next valid run can create a real event.
PRIORITIZE_GROWTH_SIGNAL_REVIEW	Inspect the high-materiality expansion and relevant functions before using it as account context.
REVIEW_CONTRACTION_SIGNAL	Validate source coverage and changed functions; do not equate contraction with layoffs.
NO_MATERIAL_CHANGE	Record the flat observation and avoid unnecessary external action.
RETRY_MISSING_SLICES	Restore complete source evidence before accepting an aggregate change.
REVIEW_SLICE_CONFIGURATION	Correct or replace an unresolved supported-slice definition.
REVIEW_HIRING_CHANGE	Inspect lower-materiality movement in context.

Confidence is not attractiveness

confidenceScore answers “how strongly does the available evidence support this factual classification?” It does not answer “how valuable is this lead, property, account, or address?” A high-confidence negative fact may be commercially uninteresting; a low-confidence positive signal may deserve research but not action. Keep the concepts separate in dashboards, exports, and CRM fields.

Why safeToAutomate is conservative

safeToAutomate is intentionally false whenever the next step could amplify an uncertain inference. It may be true only for narrow deterministic actions explicitly supported by the row, such as suppressing an email with invalid syntax. A true value does not waive legal, privacy, consent, contractual, or organizational rules.

Retry policy

Retry when retryable=true and the failure is operational, such as a temporary source or DNS problem.
Do not endlessly retry deterministic invalid input, policy refusal, or confirmed absence.
A retry must preserve the original input reference and must not create duplicate downstream actions.
Budget exhaustion is not negative evidence about the entity. Resume only the unprocessed scope with an authorized budget.
A failed Actor run is an operational event. Never transform it into “no listing,” “no contact,” “bad lead,” or “invalid email.”

Commercial use-case playbooks

1. Strategic account watch

Goal. Track two to ten company slices on a schedule and send only material, complete events to a researcher.

Recommended runbook.

Define the submitted cohort and write down why it is in scope.
Start with the smallest useful Input and preserve the exact run ID.
Inspect the Dataset overview before exporting anything.
Check failureType, retryable, completeness indicators, and confidenceBand.
Open the relevant sourceEvidence or source URL for material rows.
Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
Record the analyst's final disposition in the destination system.