DEV Community: Bobby Digital

My Mastra Agent Found a Production Bug in Five Minutes

Bobby Digital — Sat, 21 Mar 2026 20:37:18 +0000

I saw a tweet about Sentry shipping an AI agent that watches your error logs and auto-suggests fixes. I thought: I can build that. So I did — from my phone, on a Friday afternoon, while walking around the house.

I stood up a Mastra workflow via Telegram, pointed it at my three Cloudflare Workers sites, and ran it. Within five minutes it flagged scriptThrewException errors on all three sites. Bots were hitting my media proxy endpoint, the Worker was crashing on every request, and my uptime monitor had been saying everything was fine for days.

The whole thing — Mastra for the workflow engine, Cloudflare's GraphQL Analytics API for the data, a Telegram bot for alerts — runs locally on my Mac, costs nothing, and took about two hours to build. The same afternoon I pushed a blog post from a mountain via Telegram. Here's how it works and what it found.

Why "Is It Up?" Isn't Enough

I already had an uptime monitor running as a GitHub Action every 30 minutes. It hits each site, checks for a 200 response, and moves on. All three of my sites — bdigitalmedia.io, tech.bdigitalmedia.io, and truck.bdigitalmedia.io — were passing every check. Green across the board.

But the sites were throwing scriptThrewException errors on every Worker invocation. Bots and crawlers hitting API routes, the Worker script crashing, Cloudflare returning 500s — and the uptime monitor never noticed because it only checks static pages, which are served directly from Cloudflare's edge cache without invoking the Worker at all.

I needed something that could look at the actual error rates across all HTTP traffic, not just ping the homepage and call it a day.

What Is Mastra

Mastra is a TypeScript framework for building AI agents and workflows. It comes from the team behind Gatsby, it's open source (Apache 2.0), and it has over 22,000 GitHub stars. I use it at my day job and wanted to practice building workflows with it outside of work.

The core concept is simple: you define steps with Zod-validated input/output schemas and chain them together with .then(). Each step is a typed function that receives data from the previous step and returns data for the next one.

const workflow = createWorkflow({
  id: "site-monitor",
  inputSchema: z.object({ sites: z.array(siteSchema) }),
  outputSchema: z.object({ sent: z.boolean() }),
})
  .then(fetchMetrics)
  .then(analyzeFindings)
  .then(sendTelegram)
  .commit();

Three steps. Fetch the data, analyze it, send an alert if something is wrong. That's the entire workflow.

Step 1: Pulling Metrics from Cloudflare

My sites run on Cloudflare Workers. Cloudflare exposes a GraphQL Analytics API that gives you zone-level HTTP request data — total requests, status codes, response times — broken down by hostname.

The key insight: I needed zone-level HTTP analytics, not Worker invocation metrics. My sites use Cloudflare's [assets] directive, which means static pages are served directly from the edge without invoking the Worker script. If you only look at Worker invocations, you're seeing a tiny slice of traffic — mostly API routes and bot requests — and the error rates look wildly wrong.

The first version of the monitor used workersInvocationsAdaptive and reported 100% error rates on all three sites. That's because the only Worker invocations were bots crashing on API routes. The real traffic — visitors reading blog posts, browsing the portfolio, buying video clips — was invisible.

Switching to httpRequestsAdaptiveGroups at the zone level gave me the complete picture:

bdigitalmedia.io:       348 requests | 46 5xx | 13.2% error rate
tech.bdigitalmedia.io:  299 requests | 7 5xx  | 2.3% error rate
truck.bdigitalmedia.io: 231 requests | 2 5xx  | 0.9% error rate

That's real data. And the 46 errors on the main site were real errors worth investigating.

The analysis step takes the raw metrics and classifies each site based on 5xx error rate:

Healthy: under 5% error rate
Degraded: 5-20% — something is wrong but the site is mostly functional
Down: over 20% — significant portion of requests failing

It formats a clean message with status icons, request counts, error breakdowns, and HTTP status code distributions. The format is designed to be scannable in a Telegram notification — you should be able to glance at it and know if you need to act.

Step 3: Telegram Alerts (Only When It Matters)

This is the part I spent the most time thinking about. A monitor that sends a message every time it runs is a monitor you learn to ignore. The alert has to mean something.

The workflow runs in two modes:

Check mode (every 4 hours): Looks at the last 4 hours of traffic. If all sites are healthy, it stays completely silent. No message, no notification. You only hear from it when something is actually wrong.

Summary mode (daily at 7am): Always sends a full traffic report regardless of status. Total requests, error counts, status code breakdowns across all three sites. This is the morning briefing — a quick glance at how the sites performed over the last 24 hours.

The Telegram integration is straightforward. A bot token, a chat ID, and a fetch call to the Bot API. The interesting part is the suppression logic:

if (mode === "check" && !inputData.hasIssues) {
  console.log("All sites healthy — no alert sent.");
  return { sent: false };
}

Silence is the signal that everything is fine.

It Found a Real Bug

The first time I ran the monitor with real data, it flagged scriptThrewException errors on all three sites. The main site had 66 exceptions in the last 24 hours.

I dug into the Cloudflare GraphQL data with status dimensions and found the root cause: the media proxy endpoint at /api/media/[...path] had an unguarded r2.sign() call in the presigned URL fallback path. When a bot hit the endpoint and the R2 signing failed for any reason — bad path, network hiccup, missing object — the Worker crashed instead of returning a 404.

The fix was a try/catch:

try {
  const signedRequest = await r2.sign(
    new Request(`${r2Endpoint}/bdigital-clips/${path}?X-Amz-Expires=300`),
    { aws: { signQuery: true } }
  );
  return Response.redirect(signedRequest.url, 302);
} catch {
  return new Response('Not found', { status: 404 });
}

Five lines. Zero new errors since the deploy.

A monitor that finds real bugs on day one has already paid for itself. The entire tool took two hours to build, and it caught an issue that had been silently crashing in production. The uptime check said everything was fine. The error rate data told a different story.

Running It Locally

The whole thing runs locally with tsx:

npm run check      # 4h lookback, alerts only on errors
npm run summary    # 24h report, always sends to Telegram

No cloud compute, no hosting costs. Mastra runs on Node.js, the Cloudflare API is free, and the Telegram Bot API is free. The only cost is the electricity to keep my Mac awake.

For scheduling, I use cron jobs that fire the check every 4 hours and the summary every morning. If the Mac is asleep, the check runs when it wakes up. If I need persistent monitoring, the same workflow can deploy to Cloudflare Workers using Mastra's @mastra/deployer-cloudflare package — but for three personal sites, local is fine.

What Comes Next

The monitor currently tells me something is wrong. The next step is having it fix the problem.

Mastra supports agent steps — workflow steps that can reason about data, read code, and take action. The natural evolution is: when the monitor detects elevated errors, it reads the Cloudflare logs, identifies the failing endpoint, greps the codebase for the relevant file, analyzes the crash pattern, and either fixes it directly or opens a PR with the proposed fix.

I already have Claude Code running remotely and pushing to production from my phone. Connecting the monitor to an agent that can diagnose and patch production issues closes the loop. The workflow becomes: detect, diagnose, fix, deploy, verify — all without human intervention.

That's not built yet. But the foundation is here, and the workflow architecture supports it. Steps chain together. Each step has typed inputs and outputs. Adding a "diagnose" step and a "fix" step is just more .then() calls on the same workflow.

For now, the monitor runs every 4 hours, stays silent when things are healthy, and pings me on Telegram when they're not. It found a real bug on day one. That's a good start.

The full monitor workflow is about 350 lines of TypeScript. If you're building something similar with Mastra or want to talk about Cloudflare Workers monitoring, get in touch or find me on Instagram.

Originally published at https://tech.bdigitalmedia.io/blog/mastra-site-monitor-cloudflare-telegram/

I've Started Using Dumber Models on Purpose

Bobby Digital — Thu, 19 Mar 2026 19:45:08 +0000

Here's something that felt wrong at first: I've started reaching for less capable models when I'm writing code.

Not because they're cheaper. Because they make me think.

The Problem with Too-Capable Tools

Opus 4.5 will take a half-baked prompt and ship working code. You describe a vague idea, and 30 seconds later you've got something that compiles. Magic, right?

Except... did you actually think about what you were building?

The risk with ultra-capable models isn't wrong code - it's skipping the part where you understand the problem. You get a solution before you've defined what you're solving.

I found myself in meetings defending decisions I hadn't consciously made. "Why did you structure it this way?" Uh, because the model did, and it worked?

That's a problem.

Friction Is the Feature

Sonnet makes you think first. When a model requires precision in your prompts, you're forced to actually articulate what you want. That articulation is the architecture work.

My architecture decisions are sharper when the model requires precision. The prompt becomes the design doc. If I can't explain it clearly enough for a mid-tier model to execute, maybe I don't understand it well enough yet.

This isn't about the model being bad. It's about the model being appropriately demanding.

The New Workflow

Here's what works for me:

Exploration and research: Use the biggest brain available. Opus 4.5 for understanding complex codebases, exploring possibilities, asking "what if" questions. Let it synthesize.

First-draft implementation: Dial it back. Sonnet forces me to write actual specs. If the prompt has to be precise, the thinking has already happened.

Code review and debugging: Back to powerful models. They catch things I miss, suggest better patterns, and explain why something is wrong - not just that it is.

Refactoring: Sonnet again. If I can't describe the refactor clearly, I'm not ready to do it.

The pattern: powerful for exploration and review, constrained for creation.

Write the Design Doc Before the Prompt

This is the real insight: if your prompt could substitute for a design doc, you've done the thinking. If your prompt is "make it work," you haven't.

Ultra-capable models let you skip writing that design doc. Which is exactly why you shouldn't always use them.

I've started treating prompts like I treat commit messages - they should explain the why, not just the what. If the prompt is just "add user authentication," I haven't done my job. What kind of auth? Where does it live? What's the session strategy?

Forcing yourself to answer those questions in the prompt forces you to answer them in your head first.

The Counterintuitive Truth

The tool that makes you think less isn't always the better tool.

When I reach for the most powerful model, I'm implicitly saying "I don't need to think about this." Sometimes that's true - you're doing rote work, or you genuinely need the extra capability.

But for design decisions? For architecture? For anything you'll need to explain to another human?

The friction is a feature. The struggle to articulate is the work.

I'm curious - has anyone else found themselves deliberately using less capable tools for certain tasks? Not for cost or speed, but because the constraint improves the output?

Join the conversation: Comment on LinkedIn

Originally published at https://tech.bdigitalmedia.io/blog/dumber-models-on-purpose/

Building a Filterable Resume Page with PDF Export and CI/CD for Astro

Bobby Digital — Thu, 19 Mar 2026 01:37:15 +0000

Yesterday I built a Christmas gift tracker. Today I decided my portfolio site needed a resume page. And while I was at it, I set up a proper CI/CD pipeline because pushing to production without tests is chaos.

Part 1: The Resume Page

The "I Haven't Needed a Resume in 10 Years" Problem

Here's an admission: I haven't thought about my resume in probably a decade. When you're happily employed and not job hunting, that document just... sits there. Somewhere. Maybe in a Google Doc from 2015?

So when I decided to build a resume page, my first challenge wasn't technical - it was "where is my career history even stored?"

The answer, of course, is LinkedIn. I've been dutifully updating my LinkedIn profile for years, but I'd never actually extracted that data. Turns out LinkedIn has a feature for this that I'd completely forgotten about.

Getting Your Data Out of LinkedIn

LinkedIn lets you download your account data - and it's more detailed than you'd expect:

Go to Settings & Privacy → Data Privacy
Click "Get a copy of your data"
Choose "The works" (or pick specific categories like Positions, Education, Skills)
Wait for the email (minutes for specific data, up to 24 hours for everything)
Download and extract the ZIP file

What you get is a folder full of CSV files:

Profile.csv - Your headline, summary, location
Positions.csv - Every job with company, title, dates, description
Education.csv - Schools, degrees, dates
Skills.csv - All those endorsements you've collected
Certifications.csv - Professional certifications
And more...

Converting LinkedIn Export to JSON Resume

CSV files aren't directly usable for a web page, so I wrote a script to convert them to JSON Resume format:

node scripts/linkedin-to-resume.mjs ~/Downloads/Basic_LinkedInDataExport_12-22-2025/

The script:

Parses all the CSV files (handling LinkedIn's multiline quoted fields)
Maps fields to JSON Resume schema
Extracts bullet points from job descriptions as highlights
Auto-categorizes skills (Cloud, Programming, Databases, etc.)
Outputs a JSON file ready for editing

// The script handles LinkedIn's CSV format
const positions = readCSVFile(exportDir, 'Positions.csv');

const work = positions.map(pos => ({
  name: pos['Company Name'],
  position: pos['Title'],
  startDate: formatDate(pos['Started On']),  // "Jan 2020" → "2020-01"
  endDate: formatDate(pos['Finished On']),
  summary: pos['Description'],
  highlights: extractBulletPoints(pos['Description'])
}));

What LinkedIn doesn't export:

Your profile photo (you'll need to save it manually)
Detailed job highlights (the descriptions are often sparse)
Your LinkedIn URL (ironically)
Recommendations text

After running the script, I spent about 30 minutes enriching the data - adding specific achievements, metrics, and details that make a resume actually useful to recruiters.

Why Build a Custom Resume Page?

Most developers either link to a PDF or use LinkedIn. I wanted something better:

Filterable - Recruiters can filter by years of experience or company
Multiple formats - JSON, YAML, PDF, and DOCX exports
Single source of truth - Edit one JSON file, everything updates
SEO friendly - Proper meta tags and structured data

The Architecture

The resume uses the JSON Resume schema - a standardized format that means the data is portable. Edit one file, everything updates:

src/data/resume.json          # Single source of truth
    ↓
src/pages/resume.astro        # Interactive page with filtering
src/pages/api/resume.json.ts  # JSON export endpoint
src/pages/api/resume.yaml.ts  # YAML export endpoint
public/resume.pdf             # Pre-generated PDF
public/resume.docx            # Pre-generated DOCX

Client-Side Filtering

The page includes JavaScript for filtering without page reloads. Filter by years of experience (1Y, 2Y, 5Y, 10Y) or by company:

const filterExperience = (years) => {
  const cutoffDate = new Date();
  cutoffDate.setFullYear(cutoffDate.getFullYear() - years);

  document.querySelectorAll('.experience-item').forEach(item => {
    const endDate = item.dataset.endDate;
    // Show if current role OR ended within the timeframe
    const show = !endDate || new Date(endDate) >= cutoffDate;
    item.style.display = show ? 'block' : 'none';
  });
};

This means a recruiter looking for "last 2 years of experience" can click a button and see exactly that.

The PDF Generation Challenge

My first attempt used html2pdf.js for client-side PDF generation. Problem: Content Security Policy blocked the CDN script.

The solution: Build-time PDF generation with Puppeteer

Instead of generating PDFs in the browser, I created a Node.js script that:

Builds the site
Starts a local static server
Uses Puppeteer to render the resume page
Injects compact styling for a 2-page PDF
Saves the result

async function generatePDF() {
  const browser = await puppeteer.launch({ headless: true });
  const page = await browser.newPage();

  await page.goto('http://localhost:3456/resume/', {
    waitUntil: 'networkidle0'
  });

  // Inject compact styling for 2-page resume
  await page.evaluate(() => {
    const style = document.createElement('style');
    style.textContent = `
      body { font-size: 11px !important; }
      h1 { font-size: 24px !important; }
      /* Hide nav and footer for clean PDF */
    `;
    document.head.appendChild(style);
    document.querySelector('nav').style.display = 'none';
  });

  await page.pdf({
    path: 'dist/resume.pdf',
    format: 'Letter',
    printBackground: true,
    margin: { top: '0.4in', right: '0.4in', bottom: '0.4in', left: '0.4in' }
  });

  await browser.close();
}

Key insight: Puppeteer and docx are installed locally but NOT in package.json. This avoids CI conflicts - they're only needed for local PDF generation, not for Cloudflare builds.

# Local only - not in package.json
npm install puppeteer docx

# Generate resume files
npm run resume:generate

DOCX Generation

For Word documents, I used the docx library to programmatically build the document from the same JSON data:

import { Document, Packer, Paragraph, TextRun } from 'docx';

const doc = new Document({
  sections: [{
    children: [
      new Paragraph({
        children: [new TextRun({ text: resumeData.basics.name, bold: true, size: 48 })]
      }),
      // ... build document structure from resume.json
    ]
  }]
});

const buffer = await Packer.toBuffer(doc);
writeFileSync('dist/resume.docx', buffer);

Part 2: The CI/CD Pipeline

The Problem

Before today, pushing to main would deploy directly to Cloudflare Pages with no checks. A bad dependency update could break production. Case in point: Dependabot opened a PR to upgrade Tailwind CSS from v3 to v4 - a complete rewrite that would have broken everything.

GitHub Actions Setup

I created two workflows:

Main CI Workflow

Every push and PR runs:

Build & Test - Builds the site, validates all images
Security Audit - npm audit --audit-level=high fails on vulnerabilities
Lighthouse - Performance/accessibility checks (PRs only)

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'

      - run: npm ci
      - run: npm run build
      - run: npm run validate:images

  security-audit:
    runs-on: ubuntu-latest
    steps:
      - run: npm ci
      - run: npm audit --audit-level=high

Dependabot Auto-Merge

Patch and minor updates auto-merge when CI passes. Major updates get a comment explaining they need manual review:

- name: Auto-merge patch updates
  if: steps.metadata.outputs.update-type == 'version-update:semver-patch'
  run: gh pr merge --auto --squash "$PR_URL"

- name: Comment on major updates
  if: steps.metadata.outputs.update-type == 'version-update:semver-major'
  run: |
    gh pr comment "$PR_URL" --body "⚠️ Major version update - requires manual review"

Handling the Tailwind v4 PR

Today I got a Dependabot PR trying to upgrade Tailwind CSS from v3 to v4. The CI would have caught the build failure, but beyond that - this is a migration project, not a routine update.

The right approach:

CI detected it as a major update
Auto-merge was skipped
I closed the PR with an explanation
Added an ignore rule to prevent future v4 PRs

# .github/dependabot.yml
ignore:
  - dependency-name: "tailwindcss"
    update-types: ["version-update:semver-major"]

Security Vulnerability Handling

The pipeline handles security at multiple levels:

Layer	What It Does
`npm audit` in CI	Blocks PRs with high/critical vulnerabilities
Dependabot alerts	Notifies of known vulnerabilities in dependencies
Auto-merge patches	Security fixes merge automatically when CI passes
Manual review	Major updates require human approval

Results

The resume page is now live with:

Interactive filtering (1Y, 2Y, 5Y, 10Y experience views)
Company filtering dropdown
JSON/YAML API endpoints at /api/resume.json and /api/resume.yaml
Downloadable PDF (2 pages, professionally formatted)
Downloadable DOCX

The CI/CD pipeline provides:

Automatic builds and tests on every push
Security scanning for vulnerabilities
Auto-merging safe dependency updates
Protection against breaking changes

Lessons Learned

Build-time vs runtime PDF generation - Puppeteer at build time is more reliable than browser-based solutions that fight with CSP
Don't put dev-only dependencies in package.json - Puppeteer caused CI conflicts with Tailwind's peer dependencies. Keep build-only tools local.
Group Dependabot updates - Individual PRs for every patch are noisy. Grouping makes review manageable.
Ignore major versions for complex deps - Tailwind v4 is a migration project, not a routine update. Configure Dependabot to skip it.
Auto-merge what's safe - Patch updates rarely break things. Let CI validate and merge them automatically.
Security scanning should fail builds - npm audit --audit-level=high in CI catches vulnerabilities before they hit production.

The resume lives at /resume with all the export options. The JSON Resume format means I can also use it with other resume tools if I ever decide to switch.

Originally published at https://tech.bdigitalmedia.io/blog/resume-page-and-cicd-pipeline/