Introducing Signals: stop checking whether a company started hiring

Most of what the industry sells as intent data is inferred. Someone at a company read an article, visited a comparison page, or turned up in a bidstream, and a model decides that adds up to interest. It sometimes does. It is also downstream of a lot of guessing, which is why so much of it arrives as a score you cannot audit.

A job posting is a different kind of evidence. The company wrote it, dated it, published it, and attached a salary to it. Nobody inferred anything. When a business opens two analytics engineering roles, it has told you in public that it has a data problem and money assigned to solving it - usually a quarter or two before any content-intent tool notices anyone poking around.

We have served that data as an API for a while. The gap was never the data. It was that you had to go and ask for it, on a schedule you maintained, and remember what you had already seen. So we built Signals.

What a Signal is

A Signal is a search you save instead of re-running. You build it the way you already build a search - the roles, the skills, the company size, the industry, the country - and from then on JobsPipe watches the corpus for you. When something new matches, you hear about it by email, in Slack, or on a signed webhook into your own system.

There are two ways to be told. In job mode you get every new posting that matches, which suits recruiting and market tracking. In company mode you get told the first time a company enters your result set and never again, which is what you want when the thing you care about is the account, not the individual req.

The part that is harder than it looks

“Tell me what is new” sounds like a timestamp comparison. It is not, and the difference is what makes an alerting product either trustworthy or noise.

A posting can be re-crawled, re-posted by the employer, or picked up again by a backfill. If “new” means the last time we touched the row, every one of those events fires an alert for a job you were told about last week. So each posting carries the moment it first entered the corpus, stamped once and never moved, and that is the axis a Signal reads. A repost does not re-fire. A backfill of six months of history does not flood your inbox.

The second problem is the gap between a job existing and us having it. Sources are uneven; some hand over postings quickly, some take hours. If the evaluator asked “what arrived since I last looked?” and moved on, anything slow would land behind the mark and never be seen. So the window deliberately lags behind real time, and every match is written to a ledger before anything is delivered. The ledger is what guarantees you are told once - not zero times because a delivery failed, and not twice because it was retried.

How fast it actually is

Honestly: not instant, and we would rather write that down than let you discover it. A posting reaches our corpus a median of roughly 80 minutes after it appears on the source, and the evaluator sits deliberately behind that so a slow source cannot cause a miss. In practice a Signal fires within a few hours of the posting going up.

For the use cases Signals is built for - a company entering your ICP, an account staffing up a team - hours is not the constraint. If you need the feed with no waiting at all, poll the hiring signals API directly and own the loop yourself.

Two teams, same mechanism

Sales and GTM. Point a Signal at the shape of company you sell to, and let the hiring tell you when they enter it. Companies over 200 people opening data platform roles in the US or UK is a different list every week, and the week they join it is the week the problem became someone’s job.

Recruiting. The best time to reach a hiring manager is the week the role opens, before the funnel fills and before anyone has committed to an agency. Watching a specialty across every board - companies of 50 to 500 people hiring backend engineers in Germany, say - means you hear about the opening instead of finding it on a Friday sweep.

What it does not know

Signals filter on what the dataset genuinely holds: role and title, skills named in the posting, employee count, industry, country, and source. Funding stage, revenue, and whether a company sells to businesses or consumers are not in there. We are working on enrichment, but a filter that silently matches nothing is worse than one that visibly does not exist, so those are absent rather than approximated.

Evaluating a Signal costs no job credits, and neither does previewing one before you save it. You are billed for the searches you run, not for the ones we run for you. Three Signals on the free plan, ten on Builder, fifty on Scale; email everywhere, Slack and webhooks on paid plans.