Setting a self-destruct date: which window matches which engagement

The expiry input on most private-link tools asks for a date or a duration. Most people pick the default (7 days) or the longest available (a year, "never"). Neither is wrong, but neither is usually the right fit either.

The fit comes from one question: what is this link tied to? The window should outlive that thing, plus a small grace period.

Six common windows

24-72 hours — same-window iteration

The link is meant to be opened this week, possibly today. The receiver knows it's coming; the review is a single round; there's no expectation that the link will be useful next month.

Use cases:

• A new version of an AI prototype going to a specific reviewer for same-day feedback (the iteration-phase pattern)
• A draft document for one-pass review before sign-off
• An ad-hoc reference shared in a Slack DM that the team will look at this week
• A test link shared with a colleague to confirm a flow works

Why short: the link going away after the round closes the loop. Stale links from old iterations get re-opened by mistake otherwise; the short window prevents that.

7-14 days — bounded review

The receiver has a window to look at the content; the engagement concludes when they reply. The link doesn't need to outlive the reply.

Use cases:

• A consulting deliverable for first-pass client review
• A design preview during a sign-off cycle
• An interview take-home assignment (typically 7-day cap with a polite reminder at day 5)
• A pre-meeting deck for one-time read before a Wednesday call

This is what the typical "1 week" default fits. For most one-off deliveries, the host's default is correct because most one-off deliveries are bounded by a 1-2 week review.

30 days — post-event aftermath

The event happened; the link covered the lead-up and the event itself; the next month catches the stragglers (out-of-town guests, late stakeholders, the follow-up emails the organizer sends).

Use cases:

• Wedding microsites (event date + 30 days for the thank-you note window)
• Conference recap pages (post-event for the people writing follow-ups)
• Marketing campaign retros within a team

Why 30 days: long enough that the late readers catch it; short enough that the link doesn't drift into being treated as current six months later.

90 days — quarterly cycle or single-quarter relevance

The numbers in the content are correct for the quarter; the link should retire when the quarter closes.

Use cases:

• Quarterly business reviews for clients
• A consulting analysis covering Q1 numbers (a fresh Q2 analysis is the right next deliverable, not a re-read of the old Q1 page)
• NDA-bound diligence documents during a single funding round
• A research report tied to a specific market window

For interactive consulting dashboards, the 90-day window is the typical fit — the analysis is valid for the quarter, and forcing the conversation about whether to renew with updated data is part of how the engagement progresses.

6-12 months — campaign or annual cycle

The content covers a longer-running effort but still has an end date.

Use cases:

• A year-end report a team references through Q1 of the following year
• A campaign-specific landing that runs for two seasons
• An offer or pricing page tied to a fiscal year
• A reading-list page tied to a course running for a semester

The risk to watch: the receiver bookmarks the link; the campaign ends; the bookmark stays valid for another six months and points at outdated content. The expiry forces the bookmark to fail when the campaign genuinely closes.

Specific date — event-bound or launch-bound

The content's lifespan is anchored to a known calendar event, not a duration from when the link was made.

Use cases:

• Pre-launch material that should retire on launch day (the public version becomes the live page after)
• Conference RSVP pages that close when the conference closes
• A pre-announcement deck that should be unavailable after the announcement is public
• Holiday or seasonal content with a precise end

The date-based expiry is more useful than the duration when the content's relevance is anchored externally. "Retire on October 15" is clearer than "retire 30 days from upload" when October 15 is the actual deadline.

Permanent — reference, portfolio, archive

The content is meant to live indefinitely. Different decision entirely; covered in the binary expiry-vs-permanent post.

Why not pick the longest window every time

Three real costs to over-long expiry:

• Stale content gets treated as current. A Q3 report still loadable in February gets quoted as if the numbers reflect February. The link still works; the content is misleading.
• Forwards accumulate. Each month the link is alive is another month where someone might forward it to someone the original sender didn't have in mind.
• Password rotation becomes hostile. If the link is protected by a password and the password should rotate quarterly for security hygiene, a six-month link spans two passwords — confusing.

The window should match the content's natural lifespan, not the maximum the tool allows.

Why not pick a short window for safety

Equally real costs to under-short expiry:

• The receiver misses the window. A 3-day link sent Friday afternoon expires Monday before the receiver has had time to look. The sender re-issues; the friction adds up across the engagement.
• Async engagements need slack. A multi-stakeholder review where each stakeholder takes 2-3 days to circle back needs the link alive for 10-14 days, not 7.
• Re-issuing isn't free. Each re-issued link is a new URL the receiver has to track; one URL across the cycle is cleaner.

The window should match the content's reference cycle, with a small grace period — usually 25-50% extra on top of the "definitely needed" duration.

The setup pattern

For most private-link hosts, the expiry input lives next to the password and visibility settings:

1. Open the link's settings in the dashboard.
2. Pick either a duration (drop-down: 24h, 48h, 7d, 30d, 90d, 1yr, never) or a specific date.
3. Save.

For Solo / Studio tiers on most hosts, the duration options usually extend to include "never" (permanent) and "custom date". The Free / No-account tier typically caps at 7 days because the anonymous use case is bounded.

For event microsites, the specific-date pattern fits better than duration. For client deliverables, the 7-14 day or 30-day duration fits most cases. For NDA-bound material, 90-day with periodic re-evaluation is common.

What this isn't

Expiry isn't deletion. The file still sits on the host until the host's own retention policy clears it. The expiry controls visibility — the link stops resolving — but the underlying file may remain in storage for a grace window (usually 7-30 days post-expiry) in case the owner wants to reactivate.

For genuine "delete this file permanently" intent, most hosts ship a separate "Delete" action. Expiry is the visibility gate; deletion is the storage clearance. Both are useful; they're answering different questions.

The right framing: pick the expiry that matches the content's reference window. Re-evaluate when the engagement closes. Permanent is the right answer for some links; short windows are the right answer for others; matching the window to what the content actually references is the part most expiry decisions skip.