Daily Operations

A day in the life

There is almost nothing to do on a normal day. That's the point. Every night a short chain of scheduled jobs wakes up, reads fresh data off the website network, drafts finished posts from that data using fixed templates, and publishes whatever is due. By morning a new post (or two) has gone out, the logs have advanced, and no alert has fired. You can go days without touching it.

Your job as operator is not to run the machine — it's to watch that it's running, glance at what it's saying, and keep the one paid channel topped up. Think of it like a well-behaved appliance with a pilot light: you check the flame occasionally, you don't stand over it.

The nightly schedule

Five scheduled jobs make up the chain. They run in a deliberate order every night (all times UTC): MAIN builds the feed first and ships it over, then the hub drafts from it, publishes what's due, and writes a digest. Publishing runs on its own short loop all day so posts go out on time, not just at night.

What normal looks like

Healthy is quiet. If you want a one-line mental model of a good day, it's this: a post or so went out, the logs moved forward, and your phone stayed silent. Here's what each of those means concretely.

The signs of a healthy system

• Output is trickling, not flooding. Roughly one post a day at the default cadence (7 posts kept in flight ≈ one per day). Not zero for a week; not a burst of ten in an hour.
• The logs are advancing. Each nightly job appends fresh, recent timestamps to its log. Yesterday's date at the bottom of portal-gen.log means the drafter ran; today's entries in portal-pub.log mean posts are going out.
• No ntfy alerts. The system pushes a phone notification only on failure. Silence is success — a quiet channel means every job finished clean.
• The digest reads sensibly. The morning report shows a handful of posts published and a queue with more waiting, and few or no items HELD for missing facts.
• Bluesky always moves. Bluesky is free and uncapped, so it keeps posting even if X has hit its daily cap or run out of credit. If Bluesky went quiet, something upstream stalled — that's a real signal.

Monitoring & logs

Everything the system does leaves a trail in a plain text log. When you want to know what happened last night, you read a log — no dashboard required. Four logs cover the whole chain; one lives on MAIN, the rest on the hub.

A quick health glance

ssh root@64.227.29.192           # into the hub
tail -n 20 /var/log/portal-pub.log   # did posts go out?
tail -n 20 /var/log/portal-gen.log   # did drafting run, anything HELD?

The kill switch

There is one file that stops everything: /opt/portal/PAUSE. If that file exists, publish_due.py publishes nothing — on every channel, for every tenant, immediately. Drafting and reporting still run; only the outbound door is shut. It is the safest, fastest thing you can do when you're unsure.

Stop and resume

touch /opt/portal/PAUSE   # freeze ALL publishing, instantly
rm /opt/portal/PAUSE      # resume — the next 10-min loop picks up

Because the publish loop checks for that file every ten minutes, the pause takes effect within minutes and nothing is lost — queued posts simply wait. When you remove the file, the next loop resumes as if nothing happened. No accounts are disconnected, no data is deleted, no credit is spent while paused.

Cost control, in depth

The whole system costs $24/month — that's the hub droplet, and it doesn't climb as you add sites, clients, or posts. This is the economic heart of the design: because content is generated from fixed templates filling verified fields, there is no per-post AI billing. Drafting one post and drafting a thousand cost exactly the same — nothing. The system runs on a flat subscription and never uses per-token AI billing. That's a hard rule, not a preference.

The one paid channel

The single place money moves is X / Twitter. Since the free tier closed in February 2026, X charges roughly 1.5 cents per post, or about 20 cents for a post carrying a link. A $25 credit is loaded to cover it. Every other connected channel — Bluesky today, Mastodon, LinkedIn, and Meta when connected — is free.

The X daily cap

Auto-fire is made safe by a hard limit in publish_due.py: X_DAILY_CAP = 3. No more than three paid X posts go out in a day, no matter how full the queue is. Bluesky and the other free channels are unaffected — they publish uncapped. So even a runaway queue can't run up a bill; the worst case is three X posts a day.

Tuning the cadence

Cadence is the number of posts the system keeps in flight for a tenant — roughly, 7 keeps about one post a day. It's the main dial you'll ever turn, and the right setting depends on what the account is for.

Reviving a quiet account

If you're bringing a dormant account back to life, resist the urge to blast. A sudden flood of posts on a long-silent handle reads as spammy to both the audience and the platform. Start gentle — a low cadence, one post a day or fewer — and let it build a rhythm before you turn it up. Steady beats sudden.

Feeding an active account

An account that's already busy and has an engaged audience can carry more. Raise the cadence so the queue stays full and the account posts consistently. Keep an eye on the mix, though — more volume draws more from the four content families, so make sure there's enough real data (site features, tips, milestones, spotlights) to keep it varied rather than repetitive.

The operator's routine

You don't need a daily ritual — the system is built to be left alone. But a light weekly touch and a slightly deeper monthly one keep it healthy and let you spot anything drifting before it matters.

Weekly — a few minutes

1. Skim the recent logs (portal-pub.log and portal-gen.log) — confirm posts went out and drafting ran.
2. Glance at what actually got published — do the posts read well and stay on-brand?
3. Check the X credit if you're using X — top up before it runs dry if you want it to keep posting.
4. Read the latest digest report for anything unusual (a spike in HELD items, an empty queue).

Monthly — a deeper look

1. Review the last month's output as a whole — is the cadence and mix still right for each account? Tune if needed.
2. Verify backups are landing off-box — confirm recent, dated backup entries exist (see security.html).
3. Review the tenant list and any pending platform connections — anything worth finishing (Mastodon, LinkedIn, Meta)?
4. Confirm the free channels are healthy and the paid X spend is where you want it.

Capacity & limits

One hub handles far more than a single account. It's already running the owner's own network — drawing content from 177 network sites and a 47-skill marketing library — alongside separate client tenants, each isolated with its own accounts, cadence, content, and approval setting. Because content generation is free and deterministic, the drafting side has effectively no ceiling: it can write a thousand posts as cheaply as one.

The real limits are the sensible ones, not compute:

• Paid X output is capped at three posts a day per the cap — a cost guardrail, not a technical one.
• How much real data exists to draw from — the honesty guard won't invent filler, so genuine variety comes from having enough source material across the four families.
• MAIN is memory-constrained, which is exactly why the publishing brain lives on a separate hub. Keeping the two jobs split is what lets the hub scale without straining the network server.

In practice, one $24/month hub comfortably serves the owner's network plus a roster of clients — and the cost of adding another tenant is essentially zero. That flat economics is the whole point: scale doesn't raise the bill.

Common day-to-day tasks

Most of what you'll ever want to do maps to one playbook. Use this as a quick "I want to…" index — each row links to the exact steps.