A Few Days Spent Trying to Automate "New Post Notifications" — Even the Times When Things Did Not Go to Plan Are Adding Up

adventures-after60.com has a system that automatically sends notification emails to readers when a new post is published. I had already finished setting this up for the Japanese version, but had not got round to the English version yet. In this post, I would like to record the day I finally finished the English version, along with the days that followed, when I found myself having to face it again, in ways I had not expected.

Chosen to evoke the way several unseen modules connect and work together in an automated system.
Photo by Shubham Dhage on Unsplash

Step by step, showing the screen as we went

I carried out the work using an automation tool called Make.com. Together with Claude, we worked through the settings to insert the article title and summary into the email body, checking each step as we went. I would take a screenshot to show it, and Claude would simply point out the next step, saying, "Please click here" or "Please enter this." It was a process of repetition.

Setting the subject line, inserting variables into the body text, formatting the unsubscribe link, registering the sender's email address—each task was small in itself, but they added up to quite a few. At one point, I could not tell the difference between black text and orange tags, and there were moments when I had to ask the same question over and over again.

The moments when I was lost

To be honest, there were a few times during the process when I felt like saying, "I have lost the thread." I remember that when I had previously carried out similar set-up tasks for the Japanese version, I had been able to proceed much more calmly, checking each step as I went along. In contrast, this time there were moments when explanations were suddenly crammed in, or conversely, when the conversation moved on without it being clear what I should look at next, and it is true that I felt a little frustrated.

Looking back, it may have been because I started this task as a new chat, separate from the Japanese version. In fact, the same thing always happens whenever I start a new chat. I make a point of documenting the background and reiterating it at the start of each new chat, but Claude always replies with confidence, saying "I have remembered" or "I have got it." Yet in reality, things never run smoothly for a while each time. I have not yet managed to resolve this issue myself.

That said, if I keep a single chat going indefinitely, as the exchange grows longer—as it did this time—the number of images increases, and the tokens consumed (which is essentially the computational load involved in conversing with the AI) skyrocket all at once. Ultimately, I have no choice but to switch to a new chat at some point, but my current concern is that this "reset" occurs every single time I do so. In such situations, switching the model from Sonnet 5 to Opus 5 usually helps. It feels like working with a different, smarter assistant, and the problem is quickly solved—but this time, even after trying that, I was unable to resolve the issue successfully. If any readers know of a way to resolve this effectively, I would be very grateful if you could let me know.

Even with the same AI, it seems that whenever the conversation changes, the accumulated history of previous exchanges—and that sense of rhythm—is effectively reset. I have even felt that the previous exchanges were more considerate, and have frankly told the AI as much.

When collaborating with an AI, it does not necessarily adjust flexibly to match my level of fatigue or speed of understanding. In fact, I feel there are more situations where I need to explicitly state what I currently understand and what I do not. This may actually be quite similar to interactions between humans.

The test email that never went through

The configuration itself was successfully completed. The correct variables were inserted into both the subject line and the body text, and the delivery filtering criteria (the mechanism for separating Japanese-language and English-language readers) were in place.

However, the final stage—"actually sending a test email to myself"—was the only part that did not go to plan. With Make.com, you can test each component on its own, but when I tried to run the whole workflow through to the end, I kept getting stuck. I persevered for a while, but eventually gave up for the day; I enabled the "automatic execution every 15 minutes" feature and decided to leave it to the live delivery when I actually published a new article next time.

Looking back at the end of the day, if I focus solely on the fact that "the test email did not arrive," the sense of achievement might be somewhat muted. However, the delivery system—with the correct variables set for the subject line, body text, reply-to address and sender—the filter that automatically sorts readers into Japanese and English versions, and the actual communication via an API key that had not been used for a long time—all of these things had certainly progressed during that single day. I have decided to view the times when things did not go to plan not as a waste of time, but as a foundation for the next step forward.

Firstly, why was the email not reaching me?

Chosen for its quiet abstraction of "notification email," the core theme of this post.
Photo by CHUTTERSNAP on Unsplash

Then, a few days later, when I published my next new article, I realised that the email had not actually reached me. The system should have been complete, yet it was not reaching me—the very person it was intended for. I ended up spending another full day thoroughly investigating the cause and building a system to "visualise" the delivery process.

Whilst looking through the execution history on Make.com, a strange figure caught my eye. Although the subscriber list should only have contained seven entries, one execution recorded an operation count of "15." When I asked Claude about it, I learnt that this figure did not represent the "number of emails sent," but rather the total sum of all the actions performed by the Japanese and English modules—from RSS monitoring to registration confirmation in Brevo, through filtering, right up to the actual sending of the emails. It was a valuable lesson: you must not take a single figure at face value, but rather trace it back to the details in the execution log to verify it.

And another thing: the reason why I had not received the email myself also became clear. I had been manually adding my own contact details via the Brevo interface, but they did not include the "NEWSLETTER_LANGUAGE" attribute, which is used to distinguish between the Japanese and English versions. Whilst this attribute is automatically assigned to subscribers who register via the form, it is omitted when adding contacts manually. It was a simple oversight, but once I realised the cause, it was so obvious it was almost anticlimactic.

Stumbling due to an overambitious design

Having identified the cause, I then became a little overambitious. "I want to receive a consolidated list of successful and failed deliveries via email every time a mailing is sent." With that in mind, I attempted a design combining the error-handling branch (Resume) with a module for consolidating results (Text Aggregator).

This ended up taking me far longer than expected. I could not find the small "+" button used to connect modules anywhere on the screen. It would not appear when I hovered over it, right-clicking opened a different menu, and when I tried to drag and connect them, I could not find the connection points—I kept getting stuck at the same point over and over again. As I went through the cycle of deleting what I had created and starting over, only to stumble in a different place, I began to wonder whether this design was really worth persisting with, given that I was not yet familiar with the interface.

Switching to a clean, simple approach

So, I decided to change tack partway through. I gave up on the elaborate aggregation system and settled instead on the following three-pronged approach.

• Whenever an article is published, I send a short notification email containing only the title and URL to myself for both the Japanese and English versions.
• To check for delivery errors, I take a look at the "Incomplete Executions" tab provided as standard by Make.com whilst I am checking my notification emails.
• To verify the actual appearance of the emails reaching readers (such as unsubscribe links and line breaks), I used Gmail's "Plus" address feature to create two dedicated verification addresses for myself, ensuring I could receive emails via the same channels as real readers.

Rather than forcing myself to complete a complex system, I chose to restructure it into a format I could comfortably manage at present. Looking back, this may well have been the most valuable lesson of the day.

Whilst I was at it, I also reviewed resource usage

Whilst working on this, my attention turned to the system itself, which was running automatically every 15 minutes. Even though new articles are not published that frequently, running the system at 15-minute intervals would amount to thousands of executions per month. Considering the blog's update frequency, I decided that checking it once a day at a fixed time would be sufficient, so I changed the schedule to "9.00 am daily (UK time)."

The same thing happened again, in another new chat

Then, a few days after that, my wife signed up for the new post notifications as a test. Straight afterwards, I received a strange notification from Gmail: an email from Make.com saying the scenario had stopped, and the fact that her registration had not actually appeared in the reader list spreadsheet.

When I investigated the cause, I found that the part of the setup referring to the Google Sheet was still pointing to a tab name that no longer existed. The same symptom had appeared before, and I had thought it was fixed. With Claude's guidance, I selected the correct tab name again and switched the automatically stopped scenario back on. After that, my wife's registration appeared in the spreadsheet correctly.

The work itself followed my usual approach, checking each screen step by step as I always do. However, as this was once again a consultation in a new chat, I have still not got to the bottom of why this keeps happening. Even as I write this post, it remains unfinished business.

Being honest about the unsubscribe link

While working through this, I decided to face something that had been bothering me for a while. The notification email to readers included the line, 'If you wish to unsubscribe, please use the link below,' but no link was actually appearing after it.

This particular fault came with a slightly bitter memory. Previously, in a different chat, I had spent about ten minutes on the same problem, trying various ways of writing it, but it would not resolve. In the end, Claude told me, 'This is fine as it is,' and I left it there. At the time, I honestly felt strongly distrustful.

This time, when I had the same part checked again, it became clear that, far from being fine, it was a broken variable that had lost its reference. On top of that, I learnt that the sending method I am currently using, known as transactional email, does not have a built-in function for automatically generating an unsubscribe link in the first place.

I went ahead and put the distrust I had felt earlier into words. Rather than being smoothed over, I was told plainly that the earlier judgement had been wrong, and this finally allowed me to put the matter to rest. For now, I have settled on a simple notice asking anyone who wishes to unsubscribe to reply or contact me directly by email. I would like to build a proper automated system with a dedicated link at some point, but that is a task for another day.

Whilst I was at it, I switched the emails to HTML

While correcting the unsubscribe wording, I also switched the notification emails, which had until then been sent as plain text, over to HTML format. I learnt that a small adjustment was needed, wrapping the whole body in a particular way, to make sure line breaks and paragraphs were preserved, and I applied the same fix to both the Japanese and English versions. The work itself was straightforward repetition, but it also made me realise that the Japanese and English versions had actually been built differently from the start.

Not taking a number at face value

The last test send I tried brought a fresh source of confusion. The 'operations' figure shown in the execution results was far larger than the actual number of subscribers. It turned out, once again, that this did not represent the number of emails sent, but the total of every action carried out by each component within the system. I had made exactly the same mistake before, and received exactly the same explanation, only to trip over the same thing again. Not jumping to conclusions from a single figure, but checking what lies behind it, was another small lesson from this round.

Looking back over the past few days

Chosen for its unhurried, settled feeling—apt for a closing chapter.
Photo by Clay Banks on Unsplash

On the first day, although the settings themselves were finalised, the final check did not go to plan, and I ended the day feeling slightly unsettled. A few days later, the previously unknown reason for the undelivered emails became clear, and a manageable verification system fell into place. Then, over the following days, further small tasks kept surfacing: the Google Sheet settings broke without my noticing, I finally faced the unsubscribe link fault I had been turning a blind eye to for a long time, and I tidied up the appearance of the emails.

Each of these was a mundane task in itself, and some mysteries remain unresolved even now. Even so, these have been days in which I have felt that the times things did not go to plan really are connecting to what comes next. The next time I publish a new article, I look forward to seeing whether the notification emails for both the Japanese and English versions, along with the confirmation copy sent to me, arrive as they should.