Potential Issues with High Traffic

Your JavaScript implementation makes client-side API calls to GitHub's API, which will likely cause problems with high traffic due to GitHub's strict rate limits.¹

Critical Rate Limit Constraints

GitHub enforces a 60 requests per hour limit for unauthenticated requests, shared per originating IP address. With your current implementation, every visitor triggers three API calls (repo stats and releases), meaning you'll hit the limit after just 20 visitors per hour from the same IP address or network.²¹

High Traffic Scenarios

With lots of incoming traffic, you'll face several issues:

Shared IP addresses: Visitors behind corporate networks, VPNs, or NAT will share the same IP, exhausting the rate limit rapidly¹
Badge failure: Once the limit is hit, all subsequent visitors see "0" for downloads, stars, and forks until the hourly reset³
Poor user experience: Users receive 403 errors instead of updated statistics⁴

I think it's 60 request per user ip. not total. right?

You're absolutely correct! I apologize for the confusion in my previous response.

Yes, the 60 requests per hour limit is per IP address, not a total shared limit. Each unique visitor IP gets their own 60 requests/hour allocation.²²

Why It's Still a Concern

Even though each IP gets 60 requests/hour, you may still encounter issues with high traffic:

Shared IP Scenarios

Corporate networks and institutions: Hundreds or thousands of employees behind a single public IP share the same 60-request quota. If 20+ people from the same office visit your page within an hour, later visitors will see rate limit errors.²²

Mobile carriers and ISPs: Some carriers use carrier-grade NAT (CGNAT), putting many users behind shared IPs, which exhausts the quota quickly.

VPN services: Popular VPN endpoints can have thousands of users sharing the same exit IP address.

Your Specific Implementation

Your page makes 2 API calls per visitor:

1 call to /repos/edgeleap/diffsense (for stars/forks)
1 call to /repos/edgeleap/diffsense/releases (for downloads)

This means each IP can serve 30 unique visitors per hour before hitting the limit. For individual users on residential IPs, this is perfectly fine. But for shared networks, it becomes problematic.²²

When You're Likely Safe

If your traffic consists mostly of individual developers on home/residential connections, the per-IP rate limit should work well. Most won't reload the page 30 times in an hour, so you're unlikely to hit issues.²²

⁂

is there a global total for all users limit for this call?

No, there is no global total limit for all users combined on these specific API endpoints.²³

GitHub's rate limiting is structured as:

Per-IP Limits (What Applies to You)

60 requests/hour per IP address for unauthenticated requests²³
Each IP address gets its own independent quota²³

Secondary Limits (Platform-Wide Protection)

GitHub does have secondary rate limits that apply globally to prevent abuse, but these are much higher and apply to different scenarios:²³

Maximum 100 concurrent requests (across all users)²³
900 points per minute per endpoint²³
No excessive compute resource consumption²³

These secondary limits are designed to protect GitHub's infrastructure from DoS attacks and abuse, but they're not a "total requests across all users" limit. They're triggered by patterns like making too many concurrent connections or hammering a single endpoint too rapidly.²³

For Your Use Case

Your repository info endpoints (/repos/edgeleap/diffsense and /repos/edgeleap/diffsense/releases) don't have a global "total requests from all visitors" limit. Each visitor's IP gets its own 60/hour quota independently. Even with thousands of visitors, as long as they're on different IPs, they won't interfere with each other's rate limits.²⁴²³ ²⁵²⁶²⁷²⁸²⁹³⁰³¹³²³³³⁴³⁵³⁶³⁷³⁸³⁹⁴⁰⁴¹⁴²

⁂

but if it goes viral will it still work?

Yes, it will likely work if it goes viral, but there are some caveats to consider.

Why It Should Work

Your implementation makes simple GET requests to read-only repository endpoints (/repos/{owner}/{repo} and /repos/{owner}/{repo}/releases), which are among the least resource-intensive API calls. Since each visitor's IP gets its own independent 60/hour quota, even with 100,000 unique visitors, each one can load your page without interfering with others.⁴³

Secondary Rate Limit Risks

GitHub's secondary rate limits are designed to prevent abuse and could potentially be triggered if your traffic pattern looks suspicious:⁴⁴⁴³

What Could Trigger Issues

900 points per minute per endpoint: If thousands of people hit your page simultaneously (like a Reddit/HN spike), you might exceed 900 requests/minute to the releases endpoint. This limit is shared across all IPs accessing that specific endpoint.⁴⁵⁴³

Abuse detection patterns: GitHub has undisclosed secondary limits that can trigger on patterns they consider abusive. A sudden massive spike from a viral post could potentially look suspicious to their systems.⁴³⁴⁵

100 concurrent requests: If you get a massive simultaneous traffic surge, you could theoretically hit the 100 concurrent connections limit.⁴³

Real-World Likelihood

For a typical viral scenario (Product Hunt, Hacker News front page, etc.), you're probably fine because:

Traffic spikes are usually spread over hours, not seconds
The repository info endpoints are lightweight
GitHub handles popular repositories with millions of visitors without issues
Your 2 API calls per visitor is modest

If Problems Occur

Users would see your fallback values (0 for downloads/stars) and the page would still function perfectly. The badges failing gracefully is actually a good design choice.⁴⁶

Bottom line: It should work fine for viral traffic, but there's a small chance of hitting secondary limits during extreme simultaneous spikes (thousands of requests in the same minute).⁴⁴⁴³ ⁴⁷⁴⁸⁴⁹⁵⁰⁵¹⁵²⁵³⁵⁴⁵⁵⁵⁶⁵⁷⁵⁸⁵⁹⁶⁰⁶¹⁶²⁶³

⁂

is there alternative way to solve this? issue do not a have server.

Yes! Here are several serverless alternatives that don't require maintaining a server:

1. Use Shields.io (Easiest Solution)

Replace your JavaScript API calls with Shields.io badge images that handle caching automatically:⁶⁴⁶⁵

<!-- Downloads badge -->
<img src="https://img.shields.io/github/downloads/edgeleap/diffsense/total" alt="Downloads">

<!-- Stars badge -->
<img src="https://img.shields.io/github/stars/edgeleap/diffsense" alt="Stars">

<!-- Forks badge -->
<img src="https://img.shields.io/github/forks/edgeleap/diffsense" alt="Forks">

Shields.io has its own authenticated GitHub tokens with higher rate limits and implements caching, so you completely avoid rate limit issues.⁶⁶⁶⁴

2. GitHub Actions + Static JSON (No Runtime API Calls)

Create a GitHub Action that fetches stats periodically and commits them as a static JSON file:

# .github/workflows/update-stats.yml
name: Update Stats
on:
  schedule:
    - cron: '0 */6 * * *'  # Every 6 hours
  workflow_dispatch:

jobs:
  update:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Fetch Stats
        run: |
          curl https://api.github.com/repos/edgeleap/diffsense > stats.json
          curl https://api.github.com/repos/edgeleap/diffsense/releases > releases.json
      - name: Commit
        run: |
          git config user.name github-actions
          git config user.email github-actions@github.com
          git add stats.json releases.json
          git commit -m "Update stats" || exit 0
          git push

Then fetch stats.json from your own domain (no rate limits).⁶⁷⁶⁸

3. Cloudflare Workers (Free Tier)

Create a tiny serverless proxy on Cloudflare's free tier that caches GitHub API responses:⁶⁹⁷⁰

// Cloudflare Worker
export default {
  async fetch(request) {
    const cache = caches.default;
    let response = await cache.match(request);
    
    if (!response) {
      response = await fetch('https://api.github.com/repos/edgeleap/diffsense');
      response = new Response(response.body, {
        ...response,
        headers: {
          ...response.headers,
          'Cache-Control': 'max-age=3600', // Cache 1 hour
          'Access-Control-Allow-Origin': '*'
        }
      });
      await cache.put(request, response.clone());
    }
    return response;
  }
}

Deploy to stats.your-domain.workers.dev and call that instead of GitHub API directly.⁷⁰⁶⁹

Recommendation

Use Shields.io if you're okay with badge-style images. It's the fastest solution with zero maintenance. If you need the exact current design, go with GitHub Actions + static JSON - it's simple, free, and eliminates all rate limit concerns.⁶⁴⁶⁷ ⁷¹⁷²⁷³⁷⁴⁷⁵⁷⁶⁷⁷⁷⁸⁷⁹⁸⁰⁸¹⁸²⁸³

⁂

can I extract just the value from shield and use my own html design for the badges etc?

No, Shields.io doesn't provide a JSON endpoint that returns just the raw value. It only returns rendered badge images (SVG/PNG).⁸⁴⁸⁵

However, here are better alternatives to get just the values:

1. GitHub Actions + Static JSON (Best for Your Case)

This is the simplest serverless solution that gives you full control over your HTML design:

# .github/workflows/update-stats.yml
name: Update Stats
on:
  schedule:
    - cron: '0 */1 * * *'  # Every hour
  workflow_dispatch:

jobs:
  update:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Fetch and Process Stats
        run: |
          # Fetch repo stats
          curl -s https://api.github.com/repos/edgeleap/diffsense > repo.json
          
          # Fetch releases
          curl -s https://api.github.com/repos/edgeleap/diffsense/releases > releases.json
          
          # Extract just the values we need
          node -e "
            const repo = require('./repo.json');
            const releases = require('./releases.json');
            let downloads = 0;
            releases.forEach(r => {
              (r.assets || []).forEach(a => downloads += a.download_count || 0);
            });
            require('fs').writeFileSync('stats.json', JSON.stringify({
              stars: repo.stargazers_count,
              forks: repo.forks_count,
              downloads: downloads
            }));
          "
      - name: Commit
        run: |
          git config user.name github-actions
          git config user.email github-actions@github.com
          git add stats.json
          git commit -m "Update stats [skip ci]" || exit 0
          git push

Then update your HTML to fetch from your own static file:

// In your index.html, replace the current fetch calls with:
(async function () {
  try {
    const res = await fetch('https://edgeleap.github.io/stats.json');
    if (!res.ok) return;
    const data = await res.json();
    document.getElementById('downloads-count').textContent = data.downloads.toLocaleString();
    document.getElementById('stars-count').textContent = data.stars.toLocaleString();
    document.getElementById('forks-count').textContent = data.forks.toLocaleString();
  } catch (e) {
    // keep fallback numbers
  }
})();

Benefits:

Zero rate limits (you're fetching from your own domain)
Keep your exact HTML design
Updates hourly automatically
Completely free
No external dependencies

2. Create Your Own JSON Endpoint with Cloudflare Workers

Deploy this tiny worker (free tier) that returns JSON:

export default {
  async fetch(request) {
    const cache = caches.default;
    const cacheKey = new Request('https://stats-cache.example.com/diffsense');
    
    let response = await cache.match(cacheKey);
    
    if (!response) {
      const [repoRes, releasesRes] = await Promise.all([
        fetch('https://api.github.com/repos/edgeleap/diffsense'),
        fetch('https://api.github.com/repos/edgeleap/diffsense/releases')
      ]);
      
      const repo = await repoRes.json();
      const releases = await releasesRes.json();
      
      let downloads = 0;
      releases.forEach(r => {
        (r.assets || []).forEach(a => downloads += a.download_count || 0);
      });
      
      const stats = {
        stars: repo.stargazers_count,
        forks: repo.forks_count,
        downloads: downloads
      };
      
      response = new Response(JSON.stringify(stats), {
        headers: {
          'Content-Type': 'application/json',
          'Cache-Control': 'max-age=3600',
          'Access-Control-Allow-Origin': '*'
        }
      });
      
      await cache.put(cacheKey, response.clone());
    }
    
    return response;
  }
}

I recommend Option 1 (GitHub Actions) - it's simpler, requires no additional services, and works perfectly for your use case.⁸⁶ ⁸⁷⁸⁸⁸⁹⁹⁰⁹¹⁹²⁹³⁹⁴⁹⁵⁹⁶⁹⁷⁹⁸⁹⁹¹⁰⁰¹⁰¹¹⁰²¹⁰³¹⁰⁴

⁂

cloudeflare is just more deps. and cron job makes lots of commits. can I parse the shield svg somehow? I mean the value must be in there somewhere?

Yes, you can parse the value from the SVG! Shields.io SVG badges contain the text values in <text> elements.¹⁰⁵

Here's a simple solution that fetches the SVG and extracts the value:

async function getBadgeValue(badgeUrl) {
  try {
    const response = await fetch(badgeUrl);
    const svgText = await response.text();
    
    // Parse SVG as XML
    const parser = new DOMParser();
    const svgDoc = parser.parseFromString(svgText, 'image/svg+xml');
    
    // Get all text elements - the last one typically contains the value
    const textElements = svgDoc.querySelectorAll('text');
    const valueText = textElements[textElements.length - 1].textContent.trim();
    
    // Remove commas and convert to number if needed
    return valueText.replace(/,/g, '');
  } catch (e) {
    return '0';
  }
}

// Use it in your page
(async function() {
  const downloads = await getBadgeValue('https://img.shields.io/github/downloads/edgeleap/diffsense/total');
  const stars = await getBadgeValue('https://img.shields.io/github/stars/edgeleap/diffsense');
  const forks = await getBadgeValue('https://img.shields.io/github/forks/edgeleap/diffsense');
  
  document.getElementById('downloads-count').textContent = downloads;
  document.getElementById('stars-count').textContent = stars;
  document.getElementById('forks-count').textContent = forks;
})();

This works because:

Shields.io SVGs contain <text> elements with the actual values¹⁰⁶¹⁰⁵
Shields.io has its own caching and authenticated tokens, so no rate limits for you
You keep your exact HTML design
Zero additional dependencies
No commits to your repo

The only downside: You're making 3 requests to Shields.io instead of 2 to GitHub, but Shields.io is designed specifically for this use case and handles the caching/rate limiting on their end.¹⁰⁷¹⁰⁸

This is actually a clever solution that gives you the best of both worlds - Shields.io's infrastructure + your custom design! ¹⁰⁹¹¹⁰¹¹¹¹¹²¹¹³¹¹⁴¹¹⁵¹¹⁶¹¹⁷¹¹⁸¹¹⁹¹²⁰¹²¹¹²²¹²³¹²⁴

⁂

eonist/Potential.Issues.with.High.Traffic.md

Select an option

No results found

Select an option

No results found

Potential Issues with High Traffic

Critical Rate Limit Constraints

High Traffic Scenarios

Recommended Solutions

I think it's 60 request per user ip. not total. right?

Why It's Still a Concern

Shared IP Scenarios

Your Specific Implementation

When You're Likely Safe

is there a global total for all users limit for this call?

Per-IP Limits (What Applies to You)

Secondary Limits (Platform-Wide Protection)

For Your Use Case

but if it goes viral will it still work?

Why It Should Work

Secondary Rate Limit Risks

What Could Trigger Issues

Real-World Likelihood

If Problems Occur

is there alternative way to solve this? issue do not a have server.

1. Use Shields.io (Easiest Solution)

2. GitHub Actions + Static JSON (No Runtime API Calls)

3. Cloudflare Workers (Free Tier)

Recommendation

can I extract just the value from shield and use my own html design for the badges etc?

1. GitHub Actions + Static JSON (Best for Your Case)

2. Create Your Own JSON Endpoint with Cloudflare Workers

cloudeflare is just more deps. and cron job makes lots of commits. can I parse the shield svg somehow? I mean the value must be in there somewhere?

eonist/Potential.Issues.with.High.Traffic.md

Potential Issues with High Traffic

Critical Rate Limit Constraints

High Traffic Scenarios

Recommended Solutions

I think it's 60 request per user ip. not total. right?

Why It's Still a Concern

Shared IP Scenarios

Your Specific Implementation

When You're Likely Safe

is there a global total for all users limit for this call?

Per-IP Limits (What Applies to You)

Secondary Limits (Platform-Wide Protection)

For Your Use Case

but if it goes viral will it still work?

Why It Should Work

Secondary Rate Limit Risks

What Could Trigger Issues

Real-World Likelihood

If Problems Occur

is there alternative way to solve this? issue do not a have server.

1. Use Shields.io (Easiest Solution)

2. GitHub Actions + Static JSON (No Runtime API Calls)

3. Cloudflare Workers (Free Tier)

Recommendation

can I extract just the value from shield and use my own html design for the badges etc?

1. GitHub Actions + Static JSON (Best for Your Case)

2. Create Your Own JSON Endpoint with Cloudflare Workers

cloudeflare is just more deps. and cron job makes lots of commits. can I parse the shield svg somehow? I mean the value must be in there somewhere?

Footnotes