The assumption

When I saw the Buttondown section in my Scribbles blog settings, I assumed Scribbles would turn my posts into a newsletter on its own. It doesn’t. The integration stores a Buttondown username, a heading and a description, and that’s it: a theme can show a subscribe form wired to my Buttondown list. People can subscribe, and then nothing is ever sent.

I only connected Buttondown to Blips yesterday, and the form didn’t appear on the blog at all until I updated my custom theme to show it. So before anyone could subscribe and wait for an email that would never come, I built the missing piece: a monthly digest of every post, generated by an n8n workflow from the Scribbles API and created in Buttondown through its API.

Why not RSS-to-email

Buttondown’s own answer to this is RSS-to-email, and I ruled it out for two reasons.

• It’s a paid add-on. My newsletter is on Buttondown’s free plan, which includes the API but not RSS-to-email.
• The feed is too short. The Scribbles feed only carries the latest 15 posts. In a busy month I post more than that (September had 17), so a monthly digest built from the feed would quietly drop the oldest ones.

The Scribbles JSON API doesn’t have that limit. It takes a date range, pages through results, and returns each post’s full content. That made it the right source.

The workflow

The workflow has six nodes and runs on the 1st of each month at 8:00, Montreal time. It covers the previous calendar month.

1. Two triggers. A Schedule Trigger fires monthly on the 1st. A Manual Trigger lets me run the same path on demand for testing.
2. Config (Set node). Every setting lives here: the mode (draft or send), the blog ID, name and URL, the subject prefix, an optional intro note, the maximum text length per post, and whether to show categories. It also computes the month with Luxon: the previous month in the America/Toronto time zone. The date range sent to the API is padded by a day on each side, so posts near midnight UTC aren’t lost.
3. Fetch (HTTP Request). GET /api/v1/posts on the Scribbles API with blog_id, type=posts, from_date, to_date, include_content=true and limit=100, authenticated with a bearer token. n8n’s built-in pagination increments page until pagination.page reaches pagination.pages. The node retries up to three times.
4. Build Digest (Code node). Merges the pages, drops duplicates, and keeps only published posts that aren’t hidden or excluded from RSS. It then applies the exact month boundaries in Toronto time, sorts by date and builds the email body. If the month is empty, it returns nothing and the workflow stops there, so no empty email is ever created.
5. Create email (HTTP Request). POST /v1/emails on the Buttondown API with the subject, the body and a status: draft while testing, about_to_send once it’s live.

Failures go to my shared error workflow, like every other workflow on my n8n instance. A digest that silently doesn’t go out is worse than one that fails loudly.

Designing the email

The first draft was too airy, and the second one fits the same 17 posts in about a third of the scrolling.

Version one gave each post a heading, a full-width photo, a 300-character excerpt and a “Read the blip” link, with a rule between entries. On a phone, a month of blips became a long scroll with little on each screen.

Version two is built for density:

• Full text. Blips are short, so each one goes in whole, with its own links kept: the trail links, the article I’m pointing to, the YouTube video. Only posts over 700 characters get trimmed, with a “Read more” link.
• Small photos. When a post has a photo, it becomes a 96-pixel thumbnail on the right of the text.
• Tighter entries. The title is the link, followed by the date in grey. No separators, no extra links.
• Short link labels. Long URLs show as glass.photo/…/iphone-18-pro-max instead of the full address.
• No category line. My titles already carry the category ("📡✨" for blips, “→ Links 🔗” for links), so repeating it was noise. A setting brings it back.

The body is HTML, not Markdown. Buttondown accepts both, but Markdown can’t size an image or place a thumbnail beside text, and that’s what makes the layout compact. The thumbnail rows use a simple table, which is still the most reliable way to lay out two columns across email clients.

Snags along the way

The Scribbles side worked on the first run; Buttondown authentication took several tries.

• Token, not Bearer. Buttondown expects Authorization: Token <key>. My first credential was n8n’s Bearer Auth type, which sends Bearer <key>, and Buttondown answered 401 with a helpful message saying exactly which header it wanted.
• Header Auth is the fix, but its fields are literal. In n8n’s Header Auth credential, “Name” is the HTTP header name, not a label for the credential. It must be Authorization. “Value” must be Token, one space, then the key. A stray space or a re-pasted wrong key gives the same 401, so if it keeps failing, copy the key again from Buttondown’s API settings.
• Embed shortcodes in the text. A post’s plain-text version still contains Scribbles embed codes like {{yt:https://youtu.be/…}}. The builder now turns those into plain links, and YouTube embeds in the HTML become a “Watch on YouTube” link.

The subscribe form

The form lives in my custom Scribbles theme and needs no JavaScript. It’s a Liquid snippet that reads the Buttondown username from the blog settings, so changing it in Scribbles updates the form everywhere. If the username is blank, the form doesn’t render.

The form posts the email address straight to Buttondown’s embed endpoint, https://buttondown.com/api/emails/embed-subscribe/<username>, with embed=1, and opens the confirmation in a new tab. It appears in two places: the left sidebar, and under each individual post, where a reader who just finished a blip is most likely to want more. The heading and description come from the same Scribbles settings, with a default heading when they’re empty.

Where it stands

The workflow is built and tested in draft mode, and the first real issue goes out November 1, covering October.

So far every run has created a draft in Buttondown, which let me review September’s digest as a real email before anything reached subscribers. The remaining steps are small: confirm a fresh signup through the form, flip mode from draft to send in the Config node, and activate the schedule. The send path hasn’t run yet, so the first live issue is also its first real test.

What I like about this setup is that nothing is locked in. If Scribbles adds a native newsletter one day, or I move the list elsewhere, the workflow is five steps I can change or retire in an afternoon.

A week that started strong and quickly wrapped up. Sunday carried more than the next three days combined: three unrelated bugs closed in one evening, two AI-related videos watched and digested, and then the week settled into shorter, sharper sessions. Sundays are always busy. Two build threads ran through it — the saved-bookmarks web app graduated from working to trustworthy on Tuesday evening (broken-link rechecks, full backup and restore, a last-export-date readout), and on Thursday a custom visual theme for the Scribbles.page blog went from first poke to finished inside a single day with Claude Desktop. The writing-in-public iPhone 15 Pro Max to 18 Pro Max piece was the connective tissue early on, touched Sunday, promoted from sub-page to a full Craft document on Monday, resumed Wednesday, then quiet. The back half turned reflective and Apple-shaped: a note about the coming MacBook Pro, a post on being more deliberate about which Claude model fits which task, and a quick look at Cork for Homebrew. Tooling got the attention this week; the journal itself stayed lean, with Socializing and Reading unlogged all seven days, surprisingly.

A week owned by n8n — first as a problem, then as a playground. Monday night’s out-of-memory crash forced a droplet bump to 2 GB, Tuesday brought another version upgrade (2.40 → 2.41.3), and by Wednesday afternoon the Agents tab was enabled and a minimal agent was already reading Craft Daily Notes. Alongside that, the “Writing in public” iPhone 15 Pro Max → 18 Pro Max piece advanced in small increments on four separate days without shipping, making it the week’s longest-running open thread.

Reading leaned heavily Apple — John Ternus reshaping the company, Gruber on the iPhone Air, the Duo UI critique — while watching turned toward AI tooling craft: the Jev decision-model video, then two videos on Claude prompting and skill-building. The week closed on a genuine debugging win: tracing runaway Neon compute to Birchfeed’s 11-minute polling, fixed and written up the same morning. A week of infrastructure maintenance, agent curiosity, and one article that kept almost getting finished.

The setup

I run a handful of small personal web apps on Vercel. Two of them, a task manager and a bookmarks manager, store their data in the same Neon Postgres project on the free plan.

That plan includes 100 CU-hours of compute per project per month. Neon suspends the compute after 5 minutes without activity and wakes it on the next query. In theory, a database used by one person should barely touch that allowance.

The problem

Since the second half of September, my Neon compute usage had been running high, and I couldn’t find out why.

On October 3, the Neon console showed 8 CU-hours already used for the month. That was after about two and a half days.

At that pace I would run out before the end of October. My own use of the two apps didn’t seem like enough to explain it, so something else was keeping the database awake.

Does Neon have an analytics API?

My first question was whether Neon offers more detailed usage data than the console. It does, but on the free plan the useful part is not where I expected it.

• Consumption history API. It returns per-project usage by hour, day or month, but Neon’s usage documentation says it requires a paid plan.
• Project details endpoint. On the free plan, Neon points you to cumulative counters such as compute time and active time for the billing period. For my project they all came back as zero, so I relied on the console’s figure instead.
• Operations endpoint. It lists every compute start and suspend with a timestamp, and it works on the free plan. This is the one that solved the problem.

How I investigated it

I did the investigation with Claude, which has access to my Neon, Vercel and Craft accounts through MCP connectors. My web app documentation lives in Craft, so Claude could see which apps use the database before looking at any logs.

1. Check the compute configuration. The compute is fixed at 0.25 CU, the same value for minimum and maximum. Autoscaling couldn’t cause spikes, so the usage was entirely about how long the compute stayed awake.
2. Read the operations log. The compute started, stayed active for about 5 minutes 15 seconds, suspended, then started again about 11 minutes after the previous start. The cycle ran around the clock, including between midnight and 4 AM Montreal time. That ruled me out.
3. Count requests per route in the Vercel logs. Over 24 hours, the task manager received about 80 requests, almost all from bots probing for configuration files. The bookmarks app’s RSS feed received 163 requests, and none were served from cache.
4. Line up the timestamps. Each feed request matched a compute start within a second. A sample from October 3:

5. Rule out the uptime ping. An uptime check hits the bookmarks app every hour, in a burst of 5 or 6 requests. Three of those bursts arrived while the compute was suspended and didn’t wake it. The requests stop at the app’s authentication check, before any database query.
6. Identify the pollers. The logs don’t record user agents, but the two polling patterns matched two feed reader subscriptions I had added for testing: Birchfeed every 11 minutes and Inoreader every hour.

The two readers also explain how the problem built up. Inoreader’s hourly polling had been there for a while. At about 24 wakes a day, it cost roughly 16 CU-hours a month, a latent problem that stayed within the allowance. It got much worse when I started using Birchfeed, which polls far more aggressively and doesn’t let me set a polling interval per feed.

The math

On a database that scales to zero, cost follows the number of wakes, not the size of the queries. Each wake kept the compute on for about 5.25 minutes at 0.25 CU:

0.25 CU × (5.25 ÷ 60) h ≈ 0.022 CU-hours per wake

About 131 wakes a day added up to roughly 2.9 CU-hours a day. Over two and a half days, that is 7 to 8 CU-hours, which matched the console.

Over 31 days, it projected to about 90 CU-hours before any real use of the apps. A tiny query every 11 minutes was costing about as much as keeping the database on half of every day.

The fix

Both subscriptions were left over from testing and I didn’t need them, so I removed them. That took the polling away entirely.

I also considered making the feed cacheable at Vercel’s CDN, so polls would be answered without touching the database. With the readers gone, I didn’t need it. It remains the option if I subscribe to the feed again.

Now only real activity should wake the compute: my own use of the apps, writes from my automations, and two weekly archive syncs. I expect to finish October well under 100 CU-hours.

One article carried the week. The “Writing in public — Upgrading from iPhone 15 Pro Max to iPhone 18 Pro Max — Was it Worth it?” piece got four separate sessions (Sunday, Monday, Tuesday, then a late Friday night pass), moving from transferred QuickNotes toward a shaped draft, with a camera-artifact demo clip recorded alongside it.

Photography was the week’s second thread — iPhone 18 Pro Max shots went out on Glass twice, a Montreal Moment landed on Perfect Imperfections, and a batch went up on Unsplash for the first time in a long while.

Underneath the creative work ran an infrastructure storyline that ate three mornings: n8n was upgraded Wednesday (2.37.10 → 2.40.5), went down Thursday, was upgraded and restarted again, and was pinned as the likely cause of a Neon DB 80% CPU warning — which led to setting up external monitoring for it.

The week closed with polish and experimentation, using Claude AI to rework the whois.numericcitizen.me landing page and fix its sitemap, plus test runs of the Craft beta and Moments.im collections.

One project dominated the week: Writing in public — My experience upgrading from iPhone 15 Pro Max to iPhone 18 Pro Max was touched every single day, Sunday through Saturday — moving from research and drafting to an intro rewrite, a task list, references to external 18 Pro reviews, an embedded video review, and finally first-hand observations once the device actually arrived on Friday night.

The second thread was infrastructure. whois.numericcitizen.me got a weekend to-do list, a typo pass, and a partly successful footer change that hit MCP limitations, while Elements 3.0 and its MCP setup in Claude Desktop went through a first set of tests.

Smaller maintenance ran underneath: confirming the Ghost and Micro.blog weekly sync is picking up new posts, and a Saturday attempt at an n8n workflow execution issue. Reading and watching were sparse, and both fed the same interests — Apple news on Sunday, UniFi Express 7 meshing videos on Wednesday.

The shape of the week: sustained single-project momentum, bookended by anticipation on Sunday and the phone in hand by Friday.

A week of two distinct halves. It opened in full builder mode: a long-sought MCP for searching your own publications finally came together on Sunday, followed by n8n workflows that sync both the Ghost and Micro.blog archives into a Neon database so Claude Desktop can query them directly. Monday kept the momentum — an n8n upgrade, an MCP link to the official n8n docs, a delete feature shipped to Trails, and a new photo series, Montreal by night. From Wednesday onward, Apple took over: launch-day reading, leak-driven revisions to the upgrade plans, and the launch of a first writing-in-public project on the iPhone 15 Pro Max to 18 Pro Max transition, announced across Slack, Hacker News and the blog. The back half carried some weight too — a Pixelfed reflection on the 25th anniversary of 9/11 — and the week closed with **the Apple Watch Series 8 **finally landing on the upgrade list.

A week built around one big unresolved question — whether Birchfeed could replace Inoreader and become the feed backbone for the RSS Flow web app. That thread ran Sunday through Tuesday, moving from curiosity to a Claude Code exploration to a firm decision on Tuesday night to keep the existing feed management. Publishing stayed steady around it: four blog posts went out (Apple’s inflection point under John Ternus, CleanShot 5, the August digest, and anticipation for the September 9th iPhone event). Tool testing was the other constant — two Craft betas, the CleanShot 5 upgrade and its video recording, Claude Design, and Claude AI scheduled tasks all got a turn. The back half of the week tapered into lighter housekeeping and photo sharing on Moments, the photo-journaling app discovered on day one and used three times before the week was out.

I have been publishing on Ghost since October 2018. That is 677 posts, and until this week I had no good way to ask questions about any of it. I could search my own site, which matches titles. I could remember roughly what I wrote and when, which works for the last few months and fails completely for 2019.

What I wanted was to ask “what have I written about X” and get a real answer drawn from the full text of every post. Ghost offers an API but no MCP endpoint, so the obvious path was not available. Here is what it actually took, including the parts I got wrong.

Starting with what already exists

There are several community-built Ghost MCP servers. I tried one that supports the read-only Content API, and it worked immediately. Posts, pages, tags, authors, all queryable in conversation.

For about an hour I thought I was done.

The thing that quietly breaks everything

Ghost 6.0 removed support for ?limit=all and imposed a maximum page size of 100 on every API endpoint. That change is documented and reasonable, since unbounded queries hurt large sites.

The problem is how it fails. Requesting ?limit=all does not error. It returns 100 items and says nothing about the other 577.

I found this by running a curl command to measure my archive size and getting back exactly 100 posts. A suspiciously round number for a blog running since 2018. The same cap applies to any MCP server built on the Content API, which means every answer I had been getting was drawn from my most recent fourteen months of writing while presenting itself as complete.

That is worse than an error. An error tells you to fix something. This just quietly narrows your world.

There is a second limitation underneath it. Ghost’s NQL filter language has no like operator and no partial matching, and content fields are not filterable at all. You can retrieve plaintext in a response, but you cannot query against it. So even with correct pagination, there is no way to search article bodies through the API.

Ghost’s own site search works around this the same way I ended up doing: download the corpus and search it locally.

The local copy

The design that followed is unglamorous and took an afternoon.

A Postgres table holding one row per post, with the full body in a plaintext column and a generated tsvector column indexed with GIN. An n8n workflow pulls the archive weekly with explicit pagination, seven pages at 100 posts each with a one second delay between them, and upserts everything in a single round trip.

The schema is boring on purpose:

create table ghost.posts (
  id            text primary key,
  slug          text not null unique,
  title         text,
  plaintext     text,
  url           text,
  tags          text[],
  published_at  timestamptz,
  updated_at    timestamptz,
  synced_at     timestamptz not null,
  fts tsvector generated always as (
    setweight(to_tsvector('english'::regconfig, coalesce(title, '')),     'A') ||
    setweight(to_tsvector('english'::regconfig, coalesce(plaintext, '')), 'B')
  ) stored
);

The setweight calls mean a title match outranks a body match. Without them, a post that mentions a term once in passing can outrank the post named after it.

Two details in the sync are worth stealing if you build something similar.

Full reconcile, not incremental. My first instinct was a watermark on updated_at, which is what I use for feed-based syncs. It is the wrong tool here. It would save six HTTP calls a week and would never detect a deleted or unpublished post. Pulling everything self-heals.

A guard on the delete step. Every row gets stamped with the run’s timestamp, and anything older gets pruned, which is how deletions propagate. But the prune only runs if this pass fetched at least 80% of the rows already in the table. Without that check, one bad fetch silently wipes eight years of archive. This is the kind of thing you want in place before you need it.

I was wrong about the size

I nearly did not build this because I assumed the archive would blow past my database provider’s free tier. That assumption was off by roughly two orders of magnitude.

677 posts come to 3.2 million characters of body text. The table with its full-text index totals 11 MB against a 512 MB limit. I would need something like 32,000 posts to be in trouble.

A related surprise: my recent posts average about 8,400 characters while the archive average is 4,700. My writing has roughly doubled in length over eight years. I did not know that about myself before running the query.

The more useful lesson is that on serverless Postgres, storage is almost never the binding constraint for text. Compute hours are. Every query wakes the database for a minimum billing interval regardless of how fast it runs, so a scattered handful of ad-hoc searches costs more than the weekly bulk write does. Worth knowing before you optimise the wrong thing, which I did for a while.

The part I did not anticipate

With the table populated, I assumed I was finished. I was not, and the gap here is the least obvious thing in this whole project.

Nothing routes the question.

Each time you ask something, the assistant picks tools based on their names and descriptions. It sees a Ghost MCP whose tools are explicitly labelled as browsing and reading blog posts. It also sees a generic SQL tool pointed at a database it knows nothing about. Ask “what have I written about X” and the match is overwhelmingly toward the Ghost tools, which return the 100 most recent posts and no warning.

Building the better data source does not cause it to be used. You have to say so, explicitly, somewhere persistent.

I solved this with a Skill: a set of instructions that triggers on phrasings like “what did I write about X” and states the routing rule as a prohibition rather than a preference. Do not use the Ghost browse tools for search, here is why they fail, here is the table and the query shape to use instead.

The skill also pins the retrieval pattern, which matters more than I expected. Search first with ranked snippets, then fetch full bodies for only the three to five posts that are actually relevant. And read whole posts, never fragments. A paragraph mentioning a product without the surrounding argument is exactly how you end up having your own past position mischaracterised back to you.

Full-text is not semantic search

I conflated these two for a while, and the distinction is worth being precise about.

What I built matches words and their grammatical variants. Ask about “Apple Intelligence” and it finds posts containing those words. Ask “how has my thinking about AI subscriptions evolved” and it will find something, because the words appear somewhere, but it has no way to surface a post that discusses the same idea in entirely different vocabulary.

Semantic search needs embeddings, a vector column, and a model called at both index and query time. That is a real layer of work.

I deliberately did not build it. Full-text over 677 posts with English stemming handles the lookup questions well, and lookup is most of what I actually ask. If the thematic questions come back consistently thin, the embeddings layer drops into the same table without rearchitecting anything. Building it up front would have been solving a problem I had not yet confirmed I have.

What it does not do

Four posts have empty bodies. The unauthenticated Content API cannot see members-only content, so gated posts arrive with a title and nothing else. They are findable by name but their text is not indexed. Fixing that means switching to the Admin API with JWT signing, which is not worth it for four posts.

The copy is up to seven days stale. Irrelevant for archive questions, relevant if I ask about something published yesterday.

And the whole thing is lexical. When a thematic question comes back thin, the honest answer is that the tool is not built for it, not that the archive is silent.

Was it worth it

An afternoon, one database table, one scheduled workflow, and one skill file.

The first real test was asking what I had written about GuruShots, a photography game I covered in late 2018. Two posts came back with dates and links. Through the Ghost API alone, that question has no answer at all.

That is the whole point. Eight years of writing is only an archive if you can reach into it.