Update (January 18, 2026):

Well, this is embarrassing. After publishing this post and opening a GitHub issue, I discovered the feature DOES exist—I just completely missed it.

Where it actually is:

When setting up survey targeting with a date property, use the drop down to change the operator to “before” or “after” then click “Select a value” and you’ll see relative date options.

A screenshot showing how to do relative datetime targeting in Posthog
PostHog Survey relative datetime

It’s right there in the dropdown. I have no excuse except that I was tunnel-visioned on looking for it elsewhere.

The native feature is obviously better than my workaround. Use the built-in relative date selectors—they require no extra code or property management.

I’m keeping this post up because:

  1. If you’re like me and build workarounds before thoroughly checking the UI, you’re not alone
  2. The days_since_X approach still works if you need more complex logic
  3. This is a reminder to actually explore dropdown menus before writing code

The rest of this post describes the workaround I built. The native feature is simpler—use that instead.

I wanted to show a survey to RadKits users after 14 days from signup: “How’s your experience been so far?”.

Turns out PostHog surveys can only compare dates to absolute values, not relative ones.

The Problem

I have a activated_at property (date) on each user. I want to show a survey when:

  • activated_at was more than 14 days ago

PostHog lets me create conditions like:

  • activated_at is before 2026-01-03

But this doesn’t work because:

  • I’d have to update that date daily
  • The survey would target different users each day based on calendar, not activity
  • It’s not “14 days ago”, it’s “before a specific date”

I searched for operators like “is more than X days ago” or “is in the last X days”. They don’t exist for survey targeting. However, Feature flags DO support relative date comparisons (added in this PR). So the concept exists in PostHog, just not for surveys … yet.

The Workaround

Calculate the days elapsed server-side and store it as a numeric property.

# Backend code - update on every user event
days_since_activation = (datetime.now() - user.activated_at).days
client.capture(
    distinct_id=user_id,
    event="$set",
    properties={"$set": {'days_since_signup': days_since_activation}},
)

Then I can use numeric comparison in the survey:

  • days_since_signup > 14

This works, but it requires:

  • Extra property storage
  • Server-side calculation on every event
  • Keeping the property updated

It’s extra work for what should be a simple date comparison.

Why This Matters

Time-based targeting is fundamental to user research. You want to ask:

  • New users after 7 days (onboarding feedback)
  • Inactive users after 14 days (re-engagement)
  • Trial users before day 30 (upgrade prompts)
  • Long-time users at 90 days (feature discovery)

For RadKits, I need at least three of these calculated properties just to run basic user research surveys: days_since_signup, days_since_last_active, and days_since_feature_use. I shouldn’t need extra code to target users based on properties PostHog is already tracking.

Ideally:

  • Survey targeting should be as simple as activated_at is more than 14 days ago

Feature flags already support this syntax. Survey targeting should too.

Opening an Issue

I’ll be opening a GitHub issue requesting this feature. If you’re hitting the same limitation, upvote it or add your use case.

Until then, the days_since_X workaround works—it’s just overhead that shouldn’t be necessary.