PostHog / PostHog/posthog

Make network API performance metrics queryable

Open
#19,686 28 comments 47 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement feature/apm feature/replay
Dominant language
Python
Stars
39.9k
Forks
3.4k
Avg merge
7h 27m
Merged PRs (30d)
222

Description

The replay team is currently considering improving PostHog by adding the ability to query network requests response times

We already capture network calls that are made and their performance data using the browsers' built-in PerformanceObserver. But we store these in blob storage as part of the source recording so we can't query them. If these were stored in ClickHouse we could allow you to query them using HogQL.

🗂 Considered Goals

  • split ingestion so we also ingest performance data into ClickHouse
  • add the PerformanceEntry table into HogQL
    • allow search for sessions
      • by network status code
      • network response time
    • allow finding network requests
      • by their parent page
      • by their target url
      • by their resource type
      • by their network status
  • update insights (once they are converted to use HogQL) so that we can query this data in insights
    • allow graphing
      • request/response size
      • speed
      • status
  • build a performance waterfall view on top of this data per session
  • build a "lighthouse" performance view on top of this data per page
  • show "page score" in the toolbar as you navigate around your site

These goals are being considered by the Replay Team and we'd love to hear user feedback, as well as ideas for stretch goals or implementation. Please add to this issue!

If you like this idea, please leave a 👍 or ❤️ reaction on this post to vote for it -- your votes and feedback help us prioritize what to work on next!

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the existing browser PerformanceObserver capture and how its data is stored in source recordings. Then map the proposed ingestion into ClickHouse and exposure through HogQL, using the listed query, insight, waterfall, and page-score goals to define scope. Done would require an agreed implementation plan, not just one isolated change.

Written by the indexing model from the issue text.

Assessment

Tech stack
clickhouse, javascript
Domain
analytics, data, databases
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
18/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.