Automated Trust: How js17.dev Keeps Certifications Always Fresh

Imagine landing on a consultant's portfolio and seeing certifications from 2021 — no indication of whether they're still current, still relevant, still valid. You don't know if they've kept growing or stopped trying.

That's a trust problem. And it's one I decided to eliminate from this site permanently.

---

The Problem with Static Credential Lists

When the CertificationsSection launched on js17.dev, it was pulling badge data from the Credly API at build time with a 24-hour ISR revalidation window.

That's fine for a starting point. But it has a structural weakness: the data freshness depends entirely on when the Next.js data cache happens to revalidate. In practice, the page could show certification data that's a full day stale. Worse, if the Next.js cache warmed early in the morning and no visitor triggered a revalidation, the data could sit unchanged until the next build.

For a static resume PDF, stale credentials are a known limitation. For a platform that claims to be live and engineered with precision — stale data is a contradiction.

---

The Constraint: Vercel Hobby Plan

The obvious solution is a cron job that hits the Credly API and refreshes the cache every few hours.

The constraint: Vercel's Hobby plan only supports once-daily cron frequency. Any expression that runs more than once per day (like 0 */6 * * * — every 6 hours) is rejected:

Hobby accounts are limited to daily cron jobs.
This cron expression (0 */6 * * *) would run more than once per day.

This is a real infrastructure constraint. A lesser implementation would accept it, set the cron to daily, and move on. But the goal was 6-hour effective freshness, not 24-hour. So the solution needed to be smarter.

---

The Two-Layer Cache Architecture

The final system achieves 6-hour data freshness on a Hobby plan by combining two independent freshness mechanisms:

Together, these two mechanisms guarantee that:

• At 08:00 UTC: the cron fires, writes fresh data to Blob, and invalidates the page cache
• Between cron runs: any cache miss falls back to a direct Credly fetch that Next.js keeps fresh every 6 hours
• In failure scenarios: if the Blob is unavailable or the cron fails, the ISR fallback continues working independently

Neither layer is a single point of failure. Each can operate independently.

---

How It Works in Code

The implementation is three focused components.

The getCredlyBadges() function implements the priority chain:

export async function getCredlyBadges(username: string): Promise<CredlyBadge[]> {
  if (!username) return []

  // 1. Try Blob cache first (warmed by daily cron)
  try {
    const { blobs } = await list({ prefix: "credly/badges-cache.json" })
    if (blobs.length > 0) {
      const res = await fetch(blobs[0].url, { cache: "no-store" })
      if (res.ok) {
        const cached = await res.json()
        if (Array.isArray(cached) && cached.length > 0) return cached
      }
    }
  } catch { /* fall through */ }

  // 2. Fallback: direct Credly API with 6h ISR
  return fetchFromCredly(username, true)
}

The key decisions:

• Blob fetch uses cache: "no-store" — always reads the latest file, never a stale CDN copy
• ISR fallback uses next: { revalidate: 21600 } — 6 hours exactly
• The cron handler calls revalidatePath('/') after writing to Blob — ensures the home page picks up the new data immediately, not at the next ISR window

---

The Security Model

The cron endpoint is not just an open HTTP route. It's protected by a Bearer token that Vercel auto-generates and injects into cron requests:

const authHeader = req.headers.get("authorization")
if (authHeader !== `Bearer ${process.env.CRON_SECRET}`) {
  return NextResponse.json({ error: "Unauthorized" }, { status: 401 })
}

CRON_SECRET is automatically set by Vercel for projects with cron jobs. The same pattern protects all three cron routes on this site: refresh-metrics, sync-blog-metadata, and now refresh-credly.

---

The Full Cron Stack

This was the third cron job added to js17.dev's vercel.json. The platform now runs three automated background jobs daily:

Each cron follows the same pattern:

1. Fetch fresh data from an external source
2. Write it to Vercel Blob for fast, public reads
3. Invalidate the relevant Next.js route cache
4. Return a structured JSON response with a timestamp

The pattern is so consistent that adding a new cron job to this platform is now a 20-minute operation. The infrastructure scaffolding is done.

---

Why This Matters for Clients

This feature is a proxy for something bigger: the difference between a site that was built and a site that is maintained.

Static sites decay. Certifications go stale. Metrics stop reflecting reality. Content drifts out of sync with the person behind it. That decay is invisible — it happens slowly, then suddenly someone is looking at information that's six months old.

Automated, scheduled data refresh is how you prevent that without manual intervention. It runs in the background, every day, regardless of whether you're thinking about it.

---

The Changelog Is the Proof

js17.dev is now at v1.5.0, with a public changelog at /changelog that documents every deliberate improvement since launch.

The arc of changes tells a story: security hardening, legal compliance, CI/CD automation, YouTube publishing, public metrics, MongoDB sync, and now automated certification freshness. Each sprint adds capability without regression. The build passes clean on every deploy.

This is what building in public looks like when you care about the details.

---