The True-Age Application Run, From Reposted Listing to First-Batch Send

This is the morning procedure for anyone whose job queue is full of listings that all claim to be two days old. For each listing, you trace it back to the employer's applicant-tracking record and read the real first-published date. Then you sort the queue into four age windows and send every genuinely fresh application before the first review batch fills. Budget about 15 minutes of fixed work per run, plus roughly three minutes per listing.

Why "posted 2 days ago" is not the job's real age

A job board's "posted X ago" counter tells you when that board's copy of the listing was created or renewed. It does not tell you when the employer first opened the role. Several routine mechanisms reset the counter without the job being new.

Two terms first:

• An applicant-tracking system (ATS) is the software an employer uses to publish openings and collect applications. The careers page is usually its public front end.
• A req ID (requisition ID) is the employer's own identifier for one opening. It usually survives a repost.

These mechanisms make an old job look young:

• Late copies. Sometimes an integration or a recruiter adds the job to LinkedIn after it has gone live on the careers page. In that case the board's clock starts when the copy was made, not when the job first went up.
• Promoted renewals. According to a secondary summary of LinkedIn's help pages, renewing a promoted job changes its posting date.
• Closed-job reposts. LinkedIn also lets employers repost a closed job as a new posting. Earlier applicants stay reachable through the closed post. The "Reposted" tag is the visible trace, and the employer may already hold a full pile of candidates from the first run.
• ATS auto-renewal. Secondary sources claim ATSs are commonly set to refresh a listing after a fixed number of days, often 30. No vendor document I found states a default schedule. Treat this as unverified and test for it in step 4.
• Lower-bound labels. Workday career sites collapse older listings to "Posted 30+ Days Ago". That is a floor, not a date.
• No label at all. ByteDance and TikTok careers pages publish no date.

I found no primary documentation from Indeed or Glassdoor on what their age labels measure. Until you can check one, treat any aggregator's age as the age of its copy.

This matters because of where the applications pile up. Ashby analysed 13 million applications and found that the first week of a posting draws 2-2.5x the applications of each later week. So when a "Reposted" label appears on LinkedIn, it usually means you have arrived after the busiest week, not before it.

Where the real first-published date lives in each ATS

The true date sits in the ATS's public job feed or on the job's detail page. The field holding it has a different name and meaning in each system. Of the four common systems, only one documents a date field that resets on republish, and one hides the date behind a detail click.

How to read each one:

• Greenhouse. You can recognise it by boards.greenhouse.io in the URL or a gh_jid parameter on the employer's careers page. The public feed is boards-api.greenhouse.io/v1/boards/{token}/jobs, where the token is the employer's board name from the URL. Read first_published. Ignore updated_at: on one board, 232 postings carried only 29 distinct updated_at values, the signature of a bulk edit. The field name says "first", but I found no vendor statement that a repost leaves it alone.
• Lever. The host is jobs.lever.co, and the feed is api.lever.co/v0/postings/{site}?mode=json. Read createdAt. It is a Unix timestamp in milliseconds, so divide by 1,000 before converting it to a date, or the conversion will come out wrong.
• Ashby. The host is jobs.ashbyhq.com, and the feed is api.ashbyhq.com/posting-api/job-board/{slug}. Ashby's own docs define publishedAt as the ISO date-time "when the job was last published". This field cannot prove a listing is fresh. Only your first-seen log can.
• Workday. The host is myworkdayjobs.com, and the list view shows only relative text. Open the job's detail page instead. The detail record carries startDate. The page source also contains a JSON-LD block, a machine-readable schema.org JobPosting snippet, which carries datePosted; search the source for that word. Whether a Workday repost resets either value is not established.

For LinkedIn listings, When This Job Was Posted is a public tool that links a LinkedIn listing to its ATS date. For a cached copy of a careers page, use the Wayback Machine at web.archive.org.

Which ATS you will trace most often

In Refolk's index of professional profiles, US recruiter and talent acquisition profiles list Workday as a skill far more often than Greenhouse or Lever.

These counts measure self-reported skill tags on profiles titled "Recruiter" or "Talent Acquisition". They are not ATS market share. The direction is still useful for planning: the Workday detail-record step is the one you will run most.

How fast applications arrive after a job is posted

About half of a short listing's applications arrive within 48 hours, and the first week draws 2-2.5x the volume of each later week. Interview odds appear to drop sharply after about 96 hours. That last figure comes from one study whose primary source I could not retrieve, so treat it as directional.

What each number can and cannot carry:

• Wave is a UK provider, and its figures cover 7-day listings. Adding its two windows gives about 48% of applications inside 48 hours; that sum is mine. No published source gives a 96-hour share, so do not quote one.
• Ashby based its week-one finding on 13 million applications. It also found weekly application rates rose 3x over the period it studied, so pools are growing as well as filling early.
• TalentWorks reports that applying in the first 96 hours makes you up to 8x more likely to get an interview, that each day after that cuts your chances by 28%, and that it is "nearly not worth applying after 10 days". The time-of-day study used 1,610 applications. One site cites "over 160,000", which conflicts with the other reports.
• Secondary citations only: a Greenhouse benchmark is reported at 244 applications per posting in North America, up 111%. An older StartWire study found that applicants from a job's first two days filled more than a quarter of jobs, and first-week applicants filled half.

The sources disagree on the best moment:

• Much common advice says 24 to 48 hours.
• One TalentWorks summary says applications sent 2 to 4 days after posting have the highest chance.
• Another TalentWorks summary says first-24-hour odds were roughly six times higher than waiting even four days.

Here is how I resolve it. All three place the drop somewhere between day 4 and day 10, and none says later is better. So 96 hours of true age is the outer edge of fresh, not the target. Aim for the first 48 hours whenever the source date allows it.

A repost resets the board's counter. It does not reset the pile of applications already waiting.

So is it too late to apply to a job posted two weeks ago? If the source date confirms two weeks, the listing sits in the late window. It is still winnable, but a cold application lands on a pile that has mostly been read. That is why the late window goes through a person first.

The four true-age windows and the action each one gets

Sort every row into one of four windows and give each window its own action:

• Fresh: 0-96 hours of true age
• Active: 4-10 days
• Late: 10-30 days
• Stale-repost: over 30 days, or any repost flag

I derived these cut-offs from the TalentWorks 96-hour and 10-day thresholds plus Ashby's week-one peak. They are not a published standard.

What each action means in practice:

• Fast send. Submit a tailored resume and a short letter without polishing them for days. A lost day costs more than a slightly plainer letter. Tailoring is usually the bottleneck here, and it is where Refolk helps: it builds a resume tailored to each posting from your own history and drafts the cover letter, so a fresh row takes minutes rather than an evening.
• Tailored send. You still have time, but not much. Spend it on the roles you actually fit, and go deeper on the resume and letter for each one.
• Referral-first. Before applying cold, find a person at the employer: a recruiter, the likely hiring manager, or a former colleague. Then send the application alongside that contact. If no contact turns up by a deadline you set, send cold and log the reason.
• Ghost-Job Read. This is a separate check on whether the listing is a live opening at all. Do no tailoring until the listing passes it.

Exceptions that override the window

• PERM ads. PERM labor certification is the US process an employer completes before sponsoring a foreign worker for a green card. Its recruitment includes a 30-day job order with the State Workforce Agency (SWA). It also requires a Notice of Filing posted for 10 consecutive business days. All of this happens 30 to 180 days before filing. The notice exists to inform employees and is "not another way to recruit U.S. workers". The giveaways are a 30-day run, worksite notice language, and an unusually specific list of requirements. Whether such a role is open to outside applicants is not established. Do not spend fresh-window effort on it. The governing rule is 20 CFR 656.17, which you can read on eCFR.
• Several posts on one job. Greenhouse gives each post its own id and gives the underlying job an internal_job_id, so several posts can map to one job. A "new" post may be an added location on an old job. Compare internal_job_id before you call it fresh.
• Evergreen requisitions. Workday evergreen requisitions can stay open to collect candidates for recurring or hard-to-fill roles. Their age tells you nothing. Treat them as active: send tailored, without first-batch urgency.
• Reopened after a failed shortlist. The only evidence for this pattern is anecdotal; it is not established publicly. If you suspect it, referral-first is the only way to find out.

The daily true-age run, step by step

The run has seven steps, done every morning in this order. Tracing a listing to its source date (steps 2 and 3) takes under two minutes. The send deadline for each fresh row is its source date plus 96 hours, not the time you found it.

Notes on the steps that trip people up:

• Step 2. If the careers page is a custom front end, look at where the "Apply" button goes. The ATS host usually appears in that URL.
• Step 3. Write every date in one format (year-month-day, plus a time where the feed gives one). Mixed formats break the window sort.
• Step 4. If the gap between the source date and the board date lands close to 30 or 60 days, an automated renewal is the likely cause. That pattern is a heuristic from secondary sources, not a documented rule.
• Step 6. If you have more active rows than you can tailor in a day, rank them by fit, not by age. Refolk's fit score gives you that ranking without rereading every posting.

date_seen,board,board_url,board_age_text,repost_label,ats_host,req_id,internal_job_id,source_field,source_date_iso,first_seen_by_me,repost_flag,window,action,send_deadline,sent_at,reason_code

How the true-age run goes wrong

Most errors come from trusting a field that looks like a date but measures something else. For each failure mode below: what you see, why it misleads, and the check that catches it.

Ashby rows look fresh when they are not

• What you see: a recent publishedAt on a role you vaguely remember.
• Why it lies: Ashby defines the field as last published, so any republish makes an old req look new.
• Check: search your earlier captures and a cached copy for the req ID or title. If either turns it up, date the row from the earliest sighting and flag it as a repost.

Greenhouse updated_at used as the post date

• What you see: a list of jobs sorted newest first, many sharing a timestamp.
• Why it lies: updated_at is a maintenance stamp. One board showed 29 distinct values across 232 postings, which is what bulk edits produce. Ashby, by contrast, showed 814 distinct values for 814 postings. Any tool that sorts Greenhouse jobs by updated_at gets their dates wrong.
• Check: use first_published only.

Workday "30+" treated as a date

• What you see: "Posted 30+ Days Ago", logged as day 30.
• Why it lies: the label is a lower bound, not a date. The job might be 31 days old or 300.
• Check: open the detail record and read startDate, or search the page source for datePosted.

The board date belongs to a late copy

• What you see: "1 day ago" on LinkedIn for a role that has been on the careers page for a week.
• Why it lies: if an integration or a recruiter added the job to the board late, the board's clock starts then.
• Check: the careers-page or ATS date always wins over the board date.

A new post sits on an old job

• What you see: a Greenhouse post with a recent first_published.
• Why it lies: several posts, often one per location, can share one internal_job_id. The post is new, but the job and its pile of applicants may not be.
• Check: compare internal_job_id against your log. A match on an older row means you date the job from the older row.

PERM ads read as stale real jobs

• What you see: a long-open listing with oddly narrow requirements.
• Why it misleads: it may be a compliance step with a fixed 30-day run, not a role recruiting in the normal way. It is not necessarily a ghost job either.
• Check: look for the 30-day run, worksite notice language, and the narrow requirement list. Log it as PERM-likely, and note that whether outside applicants are considered is not established.

TalentWorks treated as precise

• What you see: "8x" and "28% per day" quoted as fact.
• Why it misleads: the figures trace to an older sample of about 1,600 applications that is sometimes mis-cited as 160,000, and I could not retrieve the primary page.
• Check: use the figures to set the order of the work, not to forecast your odds.

Time zone drift

• What you see: an application sent at 8am your time, which is evening for the employer.
• Why it misleads: the TalentWorks hours refer to the company's time zone, not the applicant's.
• Check: add the employer's time zone to the row and schedule the send for their morning.

Keeping the run accurate from one day to the next

Your first-seen log is the real asset. It gets more useful every day, because it is the only repost check that works the same way on every ATS. Keep every row, log a reason for every row you did not fast-send, and recheck the field definitions from time to time, because vendors can change them.

For logging, a reason code turns a vague "didn't get to it" into something you can audit at the end of the week. Use a fixed set so the codes can be counted:

LATE-REF     Late window, waiting on a referral contact (deadline set)
LATE-COLD    Late window, sent cold after no contact by deadline
STALE-GJR    Stale-repost, sent to the Ghost-Job Read
REPOST-SEEN  Req ID or internal_job_id matched an earlier row
PERM-LIKELY  30-day run, notice language, narrow requirements
EVERGREEN    Evergreen requisition, sent as active without urgency
NO-DATE      No source date found (no ATS feed, no JSON-LD, no cache)
FIT-SKIP     Fresh or active, skipped for low fit
MISSED-96H   Fresh row not sent before source date plus 96 hours

To keep the method current, recheck how each system works instead of trusting what this guide says today:

• Field meanings. Every few months, reread the Greenhouse Job Board API and Ashby Job Postings API documentation for the date fields. If Greenhouse ever documents whether a repost changes first_published, update your Table B row.
• Workday dates. When you see a Workday listing again after a repost, note whether startDate changed. A handful of your own observations beats the current "not established".
• Auto-renewal. Count how many of your REPOST-SEEN rows show gaps near 30 or 60 days. If the pattern holds in your own market, treat those gaps as confirmed renewals there.
• Your own misses. If MISSED-96H shows up more than once a week, the queue is too big for the run. Narrow your alert queries rather than shortening the trace.