This document addresses common questions and troubleshooting topics regarding CommitPulse, including contribution discrepancies, caching, rate limits, and configuration parameters.
GitHub calculates contribution data using UTC timestamps. CommitPulse syncs cache invalidation with UTC midnight to ensure consistent results.
For deep technical details, check the Real-Time Accuracy & Caching Architecture guide.
Data is cached for performance. Use &refresh=true to force fresh data.
Yes. Use the tz parameter with any valid IANA timezone.
Example:
?tz=Asia/Kolkata
Yes. Use the grace parameter to control how many days of inactivity are forgiven before your streak resets:
?grace=0— strict mode, resets on any missed day?grace=1— default behavior (1 day grace)?grace=2— lenient, forgives up to 2 consecutive missed days
Valid range is 0–7. Values outside this range are clamped automatically. See the Customization Guide for more details.
Yes — if private contributions visibility is enabled in your GitHub settings.
Yes. CommitPulse minimizes API usage via caching and optimized GraphQL queries, but if you hit the GitHub API rate limit (typically 5,000 requests per hour for authenticated users), you might see errors or missing data.
- Wait it out: Rate limits automatically reset every hour.
- Provide your own PAT: If self-hosting, ensure you've provided a valid
GITHUB_TOKENin.env.localto get the authenticated rate limit. See the Self-Hosting Guide for details. - Avoid aggressive bypassing: Avoid repeatedly using the
&refresh=trueparameter, which bypasses the cache and consumes API quota on every load. - Check GitHub API Status: Occasionally, GitHub's GraphQL API itself experiences degradation. Check githubstatus.com.