Skip to content

Add Application Logs documentation to Dashboard guide#3311

Open
Jibaru wants to merge 14 commits intomainfrom
irueda/user-5222-add-system-logs-documentation
Open

Add Application Logs documentation to Dashboard guide#3311
Jibaru wants to merge 14 commits intomainfrom
irueda/user-5222-add-system-logs-documentation

Conversation

@Jibaru
Copy link
Copy Markdown
Member

@Jibaru Jibaru commented Apr 21, 2026

Adds a new "Logs" section under Clerk Dashboard with an Application Logs overview and a supported events reference page covering all ~100+ event types.

🔎 Previews:

Screenshots image image image image image

What does this solve? What changed?

  • Adds a new "Logs" section under Clerk Dashboard with an Application Logs overview and a supported events reference page
  • Application Logs overview covers filtering (event type, actor, subject, trace ID, device, date range), log detail view, and retention per plan
  • Supported events page catalogs all ~100+ event types grouped by category (sign-up, sign-in, user, session, organization, billing, SCIM, etc.)
  • Nav structure supports future additions (e.g., Email Logs) as siblings under "Logs"

Deadline

Probably this week.

Other resources

https://linear.app/clerk/issue/USER-5222/add-system-logs-documentation

Adds a new "Logs" section under Clerk Dashboard with an Application Logs overview
and a supported events reference page covering all ~100+ event types.
@Jibaru Jibaru requested a review from a team as a code owner April 21, 2026 18:53
@vercel
Copy link
Copy Markdown

vercel Bot commented Apr 21, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
clerk-docs Ready Ready Preview Apr 24, 2026 7:50pm

Request Review

manovotny and others added 2 commits April 21, 2026 17:02
Collapse the Application Logs sub-tree into a single page so each log
type lives at one nesting level under Logs, with Supported events as an
in-page section. Prepares the structure for Email, SMS, and Admin logs
without duplicated reference pages.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
- Point the Dashboard link at the actual Logs page (`/~/logs`).
- Use the repo's relative `/pricing` convention.
- Name Production and Development explicitly in the retention note.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
@manovotny
Copy link
Copy Markdown
Contributor

Pushed some changes directly in 29b4de6.

  • Swapped the Logs link from the Dashboard root to /~/logs
  • Changed the pricing link from absolute to relative (/pricing)
  • Tightened the retention note to name Production and Development explicitly

I'll leave the rest as inline comments.

Comment thread docs/guides/dashboard/logs/application-logs.mdx
Comment thread docs/guides/dashboard/logs/application-logs.mdx Outdated
Comment thread docs/guides/dashboard/logs/application-logs.mdx Outdated
Comment thread docs/guides/dashboard/logs/application-logs.mdx

Retention periods apply equally to Production and Development instances.

## Supported events
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm guessing these 100+ events transcribed by hand. What's the plan to keep it in sync with the Dashboard's Event Catalog?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it could be good to have a script at least to perform these updates, something like:

  1. Add a new event (or update/remove a current one)
  2. Run the script
  3. Copy the output to the docs repo

It stills manually, but could work so far.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have other scripts to keep things in sync that we could borrow inspiration from.

This can be a follow up PR(s). I just want us keeping longer-term maintenance in mind.

Can you link me to the repo/source files where these originate from?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They originate from this proto file:
https://github.com/clerk/clerk_go/blob/main/api/shared/event_stream/payloads.proto

We are using the ones that have only option tag called system_log for this application logs.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I see that you have it assigned, I could also take it on, just in case.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Jibaru you're welcome to take a stab at it. I assigned it because I didn't want to lose track of it.

Distinguishes a public breach database match (`pwned`) from an
admin- or policy-triggered mandatory reset (`compromised`) so folks
filtering logs know which signal they're looking at.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
Comment thread docs/guides/dashboard/logs/application-logs.mdx Outdated
Comment thread docs/guides/dashboard/logs/application-logs.mdx Outdated
Correct the retention periods for Business (60 → 30 days) and
Enterprise (120 → 30 days) plans to match the actual values.
Remove duplicate user-scoped email address and phone number event
sections (user.email_address.* and user.phone_number.*) and add
missing verified events (email_address.verified, phone_number.verified)
to the standalone event tables.
Update web3 wallet event types to match the proto system_log
definitions by removing the `user.` prefix.
@Jibaru
Copy link
Copy Markdown
Member Author

Jibaru commented Apr 23, 2026

Adding this too
image

@manovotny
Copy link
Copy Markdown
Contributor

Adding this too

Two thoughts:

  1. I'm torn if the Logs folder should have beta on it. Application Logs for sure.
  2. For all betas, we add a warning callout at the top. Since there's just one page (for now), you don't have to make a partial, but here's some examples for Expo and MCP server we have for right now. This should go at the very top of the Application Logs page.

Comment thread docs/guides/dashboard/logs/application-logs.mdx Outdated
Add a beta warning callout at the top of the Application Logs
page and a (Beta) tag to the navigation entry in the manifest.
The note about payloads being omitted from the list view exposed
backend implementation details not relevant to users.
@Jibaru
Copy link
Copy Markdown
Member Author

Jibaru commented Apr 23, 2026

Updated with all of your feedback. Only missing the url we are going to use to redirect to the Logs Dashboard. @brunol95 @manovotny

manovotny and others added 2 commits April 23, 2026 14:56
Move the web3 wallet subsection alongside Email address and Phone
number at the top level so its placement matches its prefix-less
identifiers, and tighten the descriptions to match the generic phrasing
those sibling sections use. Mark the page title as beta.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
The (Beta) manifest tag and the beta WARNING callout added in fc3530f
already signal beta status, so keep the page title clean.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
@manovotny
Copy link
Copy Markdown
Contributor

Pushed some changes directly in 1acbfdf.

  • Promoted Web3 wallet events out of the User events nest to a top-level section alongside Email address and Phone number, since the identifiers no longer carry the user. prefix. Tightened the descriptions to match the generic phrasing those sibling sections use.
  • Dropped my local (beta) from the page title — the (Beta) manifest tag and the beta WARNING callout already cover it.

@dmoerner
Copy link
Copy Markdown
Contributor

dmoerner commented Apr 23, 2026

Nice work @Jibaru! The web3 wallet events look out of place under the "User" heading, perhaps they should have their own heading like email and phone. It looks like Michael just fixed that 😂

@manovotny
Copy link
Copy Markdown
Contributor

All we're waiting on is the final url, correct?

@Jibaru
Copy link
Copy Markdown
Member Author

Jibaru commented Apr 24, 2026

All we're waiting on is the final url, correct?

Yes, and an approval from project leader

The Enterprise plan offers custom retention periods rather than
a fixed 30-day limit. Update the retention table to reflect this.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants