The organization
This case study comes from a small team that maintains a public resource hub for the movement, with pages of curated links pointing advocates to research, tools, and guides across many external sites.
The problem
External sites move pages, retire content, and reorganize without notice. A broken link leaves a visitor without the resource they expected and makes the library look out of date.
Checking hundreds of outbound links one by one would be difficult for the small team, so dead links used to remain until someone found them.
What they built
Vegan Hacktivists worked with the team to understand the problem, built a monitoring tool in Google Apps Script and custom JavaScript code that checks every link in the library to see if it’s active and accurate, and helped staff set up the tool in the team’s own Google account. AI helped assess the task and write the code. The deployed monitor uses deterministic rules: it requests URLs, records responses, and flags results for staff. It does not call an AI model while it runs.
How it works
- An Apps Script web app starts from the library’s index page and stores its run state in Google Sheets, so long runs can resume after a pause.
- The monitor discovers the outbound URLs across the library’s pages.
- It runs batched HTTP checks in the background, working through the list a chunk at a time.
- For every link, it records the status code, any redirect target, and an error category.
- A lightweight dashboard (a small web app also built and deployed in Google Apps Script) shows run status and results, and lets staff start a rerun when they want fresh data.
- Staff review the flagged links and decide what to fix before any change reaches the public library.
What it produces
- A list of broken, redirected, and risky links, with enough detail to act on
- Status data stored in Google Sheets, where the team can sort and filter it
- A simple dashboard for monitoring runs and triggering reruns
Where humans stay in the loop
Staff review every flagged result before anything changes on the public site.
Redirects are the clearest case. Some are harmless because a site reorganized and forwards visitors correctly. Others lead somewhere that no longer matches what the library promised. Request failures can also mislead: a site might be temporarily down or block automated requests while working for visitors. Pages with unusual structures need occasional spot checks to confirm the monitor read them correctly.
The monitor flags potential problems, and staff decide what changes. Nothing is removed, replaced, or rewritten in the library automatically.
Why it works
- It is a repetitive, rules-based task. Each URL check returns concrete data that the monitor can record the same way hundreds of times.
- Google-native tooling is lightweight for a small team. Apps Script runs inside the Google Workspace the team already uses: no servers to maintain, no new vendor accounts, no monthly automation bill.
- AI helped build the monitor. Vegan Hacktivists used it to assess the task and write the JavaScript. Each recurring check stays deterministic, so staff can trace the result to an HTTP response.
What to copy
- Use AI to plan and write Google Apps Scripts. A coding agent can inspect your site’s structure, identify how it exposes links, draft the script, and help test it. Ask Codex or Claude Code for help when you are unsure how to start, then review and test the generated code before giving it access to your account.
- Choose a runtime that fits your website. Google Apps Script worked for this team. A scheduled coding-agent task or an agent workflow could handle the same job on another site. If a later step needs judgment, you can add AI there while keeping the URL checks deterministic.
- Separate build-time AI from the running system. AI can help design and write a monitor even when the finished job runs on deterministic JavaScript.
- Let a long job pick up where it left off. Saving progress to a spreadsheet meant a multi-hour check could survive an interruption instead of starting over.
- Categorize failures instead of recording pass/fail. “Broken,” “redirected,” and “request failed” each call for a different human response. Richer categories speed up review.
