PostHog
Queries are POST with scope query:read. Use a sheet or push, not a stored-secret job.
What you can track
Daily active users, signups and funnel counts, once something that can POST to PostHog writes the number into the sheet or the push address.
Credential
A personal API key with scope query:read. Host is us.posthog.com or eu.posthog.com, matching the project. Suggested name: POSTHOG_KEY. The members-area guide says to limit the key to the project and to read scopes for Query and Insights. The query reference checked here names query:read on POST /api/projects/:project_id/query/.
Where to get it
PostHog → settings → Personal API keys. Query API.
tlly job
Do not create a fetch job against /query/. It is a POST, and a stored secret cannot be sent on it. Use the sheet or the push address.
A GET to retrieve an already-created query by id exists (GET /api/projects/:project_id/query/:id/) and also needs query:read. It returns a query you created earlier, not a standing daily metric. This playbook does not give a job for it.
Gotchas
- US and EU clouds are different hosts. The secret is bound to one host.
- HogQL in the documented example selects event properties. That is rows of text, not a single number, and it is still a POST.
Alert ideas
Red when daily active users drop under the floor the user sets. Yellow when signups are zero on a weekday.
Verification
Checked 2026-10-26: POST /api/projects/:project_id/query/ with Authorization: Bearer and required scope query:read. The overview URL is the one the members-area provider already links. Project-id path and HogQL body were on the query page. No numeric rate limit was copied.