Why run this as a Lambda Cron rather than a background job inside the web app?

The web app runs on AWS Lambda via SST, but individual requests time out in seconds. The monthly report job can take several minutes depending on the number of Pro users — each one involves a round trip to the Anthropic API plus database writes. A dedicated Cron Lambda with a 15-minute timeout handles that cleanly without blocking any web tier. If we ever hit limits, the natural upgrade path is AWS Step Functions: one function per user, fan-out and fan-in, and each step has its own timeout budget.

How does structured JSON output from the Anthropic API hold up in practice?

Well enough that we ship it directly to the frontend. The system prompt specifies the exact JSON shape, instructs the model to output only JSON and nothing else, and we extract the payload with a regex that tolerates markdown code fences. In practice, Claude 3.5 Sonnet rarely deviates from the schema when the instructions are precise. The one robustness measure we added is graceful fallback: if JSON.parse throws, we log the raw response and skip that user's email notification rather than crashing the entire batch.

What does the 30,000-character input cap mean for heavy diarists?

We pull at most 50 entries for the month and concatenate them into a single string. If that string exceeds 30,000 characters, we truncate. The important design choice is that the statistics — total entries, total word count, longest streak — are computed from the full untruncated dataset before we apply the cap. Only the text sent to the AI is limited. For users who write more than 50 entries in a month, we extrapolate total word count from the sampled subset rather than reporting a lower-than-real number.

Why does the email contain only a summary and one highlight instead of the full report?

Deliberately. The email is a hook, not a delivery mechanism. Showing the full report in the email removes the reason to open the app. The CTA at the bottom of every monthly email links directly to the in-app report page, where users get the full emotion trend graph, all topic tags, and every highlight quote. Click-through rate from the email to the app has been consistently higher than engagement from in-app notifications alone.

How do you handle the Anthropic API rate limits across many concurrent users?

We process users sequentially, not in parallel, and add a 100 ms delay between each API call. This is intentionally conservative: at the scale of a small subscription product, a single Lambda with sequential processing is simple, predictable, and well within rate limits. If we ever scale to thousands of Pro users, the right fix is a queue-based architecture (SQS + multiple Lambdas) rather than tuning the sleep interval.

How does the multi-language support work for diary analysis and email?

Two separate concerns. For diary analysis, the AI prompt instructs the model to respond in the same language as the user's diary entries. Claude auto-detects the input language reliably enough that we have not needed any explicit language detection step. For email delivery, the email templates are pre-translated into 10 languages and selected at send time based on the user's locale setting stored in the database. Adding a new email language is a matter of dropping a new template file — the dispatch logic requires no changes.

How we built AI-powered monthly reports for a diary app using Lambda and Anthropic

Storyie ships a monthly report for every Pro user: on the first of each month, an automated job reads their previous month's diary entries, runs them through the Anthropic API, and emails a concise analysis covering emotion trends, recurring topics, and memorable quotes. This post is about how that pipeline is designed and the decisions that made it reliable.

TL;DR

An SST Cron triggers a Lambda on the first of each month (production only). 15-minute timeout, 1 GB memory.
The job fetches Pro users, retrieves their prior-month diaries, converts Lexical JSON to plain text, calls the Anthropic API, writes results to monthly_reports, and enqueues an email notification.
Input is capped at 50 entries and 30,000 characters. Statistics are computed from the full dataset before the cap is applied.
The AI response is structured JSON defined precisely in the system prompt.
The job is fully idempotent: if a report already exists for the target month, it skips that user.

| Concern | Approach |
| -------------------- | ---------------------------------------------------------------- |
| Scheduling | sst.aws.Cron, cron(0 3 1 * ? *), production stage only |
| Compute | Lambda, 15 min timeout, 1 GB RAM |
| AI model | Claude 3.5 Sonnet via Anthropic API |
| Input limits | 50 entries max, 30,000 characters max (stats computed pre-cap) |
| Output format | Structured JSON (emotionTrend, topics, highlights, summary) |
| Multi-language | AI auto-matches diary language; email uses locale-based templates |
| Email delivery | Queued via email_queue table, processed by a separate Cron |
| Idempotency | DB check before insert; safe to retry on partial failures |

Why build this

Retention in a diary app depends on giving users a reason to look back. Reading your own old entries is valuable but has a high activation cost. An AI-generated recap lowers that cost to zero: the report shows up in your inbox on the first of the month, summarizes the emotional arc of your last thirty days, and surfaces a sentence you wrote that you'd likely forgotten.

For us it also anchors the Pro plan. Free users don't get monthly reports, which gives subscribers a recurring tangible benefit.

Architecture

1st of every month, 03:00 UTC
  ↓
SST Cron → Lambda (15-min timeout)
  ↓
1. Fetch Pro users from DB
2. Fetch each user's prior-month diary entries
3. Convert Lexical JSON → plain text
4. Call Anthropic API for analysis
5. INSERT into monthly_reports
6. Enqueue email in email_queue

The Cron is defined in sst.config.ts and is only provisioned when stage === "production":

if (stage === "production") {
  new sst.aws.Cron("MonthlyReportGenerator", {
    schedule: "cron(0 3 1 * ? *)",
    job: {
      handler: "packages/jobs/src/handlers/reports/monthlyReport.handler",
      runtime: "nodejs22.x",
      timeout: "15 minutes",
      memory: "1024 MB",
    },
  });
}

The 15-minute timeout and 1 GB memory allocation exist because the job's runtime grows linearly with the number of Pro users — one Anthropic API call per user. For the current scale of a small subscription product, a single sequential Lambda handles this comfortably. Step Functions would be the natural upgrade path if that changes.

The design decisions

1. Lexical JSON to plain text

Storyie stores diary content as Lexical editor state — a JSON structure that captures node types, marks, and nesting. To pass diary content to the AI, we need readable text, not JSON.

The conversion is handled by extractPlainTextFromLexicalWithNewlines, a helper that walks the Lexical node tree and preserves paragraph breaks. That last part matters: naively extracting text nodes concatenates all content into a single wall of text, which degrades the AI's ability to track context across separate thoughts. Keeping paragraph boundaries in the plain text output consistently produces better analysis.

2. Input size limits

Two constraints apply before anything reaches the API:

Entry count: at most 50 entries per user (MAX_DIARIES_PER_USER)
Character count: concatenated text truncated at 30,000 characters (MAX_INPUT_CHARS)

Critically, statistics — total entries, total word count, longest streak — are derived from the full untruncated set. Only the text that goes to the AI is limited. For prolific writers, word count is extrapolated:

const totalWords =
  totalEntries <= MAX_DIARIES_PER_USER
    ? sampledWords
    : Math.round((sampledWords / userDiaries.length) * totalEntries);

This prevents the report from claiming someone wrote 3,000 words in a month when they actually wrote 12,000.

3. Structured JSON output

The system prompt defines the exact response schema and instructs the model to return only JSON:

const systemPrompt = `You are a diary analysis expert.
Respond using the following JSON format only. Output JSON and nothing else.

{
  "emotionTrend": [...],
  "topics": [...],
  "highlights": [...],
  "summary": "..."
}`;

Structured output serves three things at once: the frontend can render each field without post-processing, the email pipeline can pull summary and highlights[0] directly, and idempotency checks can reliably store and compare the result. Extraction uses a regex that strips markdown code fences if the model wraps its output in them.

4. Multi-language handling

Diary language is not uniform — some users write in English, some in Japanese, some mix both. Rather than running language detection and branching on the result, the system prompt instructs the model to respond in whatever language the diary entries are written in. This works reliably in practice.

Email templates are a separate concern. We maintain pre-translated templates for 10 locales; the dispatch step selects the right one from the user's stored locale preference. Adding a new email language requires only a new template file.

5. Streak calculation

The monthly streak — longest run of consecutive days with at least one entry — sounds simple but has a timezone trap. Dates from the database include time components, and comparing them directly can incorrectly count two entries at 23:55 and 00:05 as two separate days.

We normalize every entry date to UTC midnight before building the sorted day array:

const sorted = [...dates]
  .map((d) => {
    const dt = new Date(d);
    return Date.UTC(dt.getUTCFullYear(), dt.getUTCMonth(), dt.getUTCDate());
  })
  .sort((a, b) => a - b);

const uniqueDays = [...new Set(sorted)];

The Set deduplicates entries that fall on the same calendar day, so multiple entries on one day count once toward the streak.

Email pipeline

After writing to monthly_reports, the job enqueues a record in email_queue — a separate table processed by another Cron (the EmailQueueProcessor) that handles actual delivery via Resend. Decoupling generation from delivery means a transient email failure doesn't require rerunning the AI analysis.

The email body is intentionally minimal:

- **Entries:** {diaryCount}
- **Total words:** {totalWords}
- **Longest streak:** {streakDays} days

### Topics you wrote about most
{topTopics}

### This month's highlight
> {highlightQuote}

We deliberately do not include the full report in the email. The email is a hook; the full report lives in the app. Every email ends with a CTA linking to the in-app report view, and click-through rates from the email consistently outperform in-app notification opens.

Cost

At the scale we're operating, Claude 3.5 Sonnet costs a few cents per user per month. Total monthly spend across all Pro users stays in the single-digit dollar range. Lambda execution cost is negligible. The 100 ms inter-request delay between users keeps us comfortably within Anthropic API rate limits without rate-limit errors, and it slows the Lambda run by a few seconds at most.

Operational lessons

Idempotency is non-negotiable. Lambda functions can be retried — by AWS on failure, or by us when debugging. The job checks whether a report already exists for the target user and month before calling the API or writing to the database. If a report is present, the user is skipped. This makes the entire job safe to rerun at any point with no risk of duplicate reports.

Structured logs pay off immediately. Every meaningful event is emitted as a JSON object to stdout:

console.log(JSON.stringify({
  event: "report_generated",
  userId,
  diaryCount: userDiaries.length,
}));

CloudWatch lets you filter on event: "report_generated" or query for a specific userId without parsing free-form log lines. When a user reports a missing report, the investigation takes seconds rather than minutes.

Production-only scheduling eliminates accidental costs. Without the stage === "production" guard, the Cron would fire in every SST stage — including local dev and staging. That would burn Anthropic API credits and send test emails to real users. The guard is a single conditional around the entire sst.aws.Cron block.

Takeaways

SST Cron + Lambda handles low-frequency batch jobs cleanly for subscription-scale products. Step Functions is the natural next step if parallelism becomes necessary.
Preserving paragraph structure when converting Lexical JSON to plain text noticeably improves AI output quality.
Computing statistics from the full dataset before applying input size limits means heavy users get accurate numbers even when the AI sees only a sample.
Structured JSON output from the system prompt makes the same AI response usable by the frontend renderer, the email template, and the idempotency check — no transformation layer required.
Idempotency and production-only guards are not optional for any scheduled job that calls a paid external API.

Building a Monorepo with pnpm and TypeScript — workspace conventions, including how packages/jobs fits into the dependency graph
Cross-platform Lexical with use dom: monorepo gains and the bridges you still own — how Lexical JSON is produced and how we share the format across web and mobile
Storyie Subscription and Billing — how the Pro plan is structured and what other features it unlocks

Try Storyie

Monthly reports are a Pro feature. Start a free account at storyie.com and write for a month — the report arrives in your inbox on the first.