finding-deleted-feature-flags

Finds soft-deleted PostHog feature flags within a time window by cross-referencing SQL results with per-flag activity logs.

713|118|Updated Aug 11, 2020
One-click install
npx skills add https://github.com/PostHog/posthog-foss --skill finding-deleted-feature-flags
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: finding-deleted-feature-flags
Source: https://github.com/PostHog/posthog-foss/tree/main/products/feature_flags/skills/finding-deleted-feature-flags
Command: npx skills add https://github.com/PostHog/posthog-foss --skill finding-deleted-feature-flags

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve?

PostHog's system.feature_flags table exposes a deleted boolean but no deletion timestamp, so there is no single SQL query that answers "which flags were deleted recently and by whom." This Skill works around that gap by combining a SQL enumeration of soft-deleted flags with parallel per-flag activity-log lookups to recover the actual deletion time and the user who deleted each flag.

Core Features & Use Cases

  • Two-stage deletion audit: Enumerates soft-deleted flag candidates via SQL, then fans out parallel activity-log lookups to extract the real deletion event, timestamp, and deleter.
  • Original key recovery: Strips the ":deleted:<id>" tombstone suffix from renamed flags using a deterministic script, so reports show the flag's original key.
  • Windowed reporting: Filters deletion events to a user-specified window (e.g. last 7 or 30 days), flags borderline cases near the cutoff, and states methodology coverage in the final table.
  • Use Case: A user asks "what flags got deleted last week?" The Skill queries soft-deleted flags, checks the activity logs of the top candidates in parallel, and returns a table of flag ID, original key, deletion time (UTC), and deleter.

Quick Start

Ask the assistant to list all feature flags deleted in the last 7 days in the active PostHog project, including who deleted each one.

Frequently Asked Questions about finding-deleted-feature-flags

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I find recently deleted feature flags in PostHog?

Query system.feature_flags for deleted = true to get candidates, then call the feature-flags-activity-retrieve endpoint for each candidate to find the entry where activity equals "deleted". That entry's created_at is the actual deletion time and its user field identifies the deleter.

Why can't I filter deleted PostHog feature flags by deletion date in SQL?

The system.feature_flags table exposes the deleted boolean but not deleted_at, updated_at, or last_modified_at, so filtering by deletion time returns an "Unable to resolve field" error. The deletion timestamp only exists in the per-flag activity log, which must be queried one flag at a time.

How do I recover the original key of a soft-deleted feature flag?

Soft-deleted flags still referenced elsewhere are renamed to "<original>:deleted:<flag_id>". Strip that suffix deterministically with the strip_deleted_suffix.py script rather than reading the activity log's detail fields, which are unreliable on API or programmatic deletes.

Can I get deletion activity for all PostHog feature flags in one API call?

No, there is no bulk activity endpoint. You must call feature-flags-activity-retrieve once per flag id, but issuing all calls in a single parallel batch makes checking around 100 candidates practical.

What are the limitations of auditing deleted feature flags this way?

Ordering candidates by created_at is only a heuristic, since an old flag can be deleted recently and missed by sampling. Walking the full candidate set is possible but slow, and deletions near the window boundary should be surfaced as borderline rather than dropped.