Answer
How we tell brands about an incident, planned maintenance, a lost connection, a change or a policy change, and the one place Seeti may appear in them.
Today
No notice system exists. Nothing tells a brand about an incident, maintenance or a change except what is below.
| What exists | Detail | Source |
|---|---|---|
| Writing paused | A one time toast when AI writing is paused: Our writing is paused for a while. Everything here still opens; new replies, drafts and rewrites wait until it’s back. |
brew/public/app.js:2966-2967 |
| Plays paused | The feed's paused card: The plays are paused with how many Plays are written |
brew/public/app.js:1609-1615 |
| A sign in running out | An email to admins 7 days ahead and when it runs out | brew/connectors/index.js:53, 480-493 |
| A stale connection | Last numbers are marked stale after 72 hours or 3 failed reads | brew/connectors/index.js:53, 474-478 |
| Alerts to us only | Billing, quota, AI pause, treg, server errors, Sloosh, worker and queue alerts go to our inbox, never to brands | brew/alerts.js:1-12 |
| Monitoring to us only | Uptime and alert policies email param@ and hello@ | brew/docs/production.md:114-115 |
| Releases | Each release promotes staging's exact image and rolls back on a failed check | brew/tools/promote.sh:1-9 |
| Policy | Privacy and Terms are preview pages dated 19 October 2026. A full policy comes before the product opens to everyone. | brew/legal-pages.js:6, 18-19, 35-36 |
| Known after a release | The first load after a release is slow. Noted 25 Oct. | memory brew-qa-round2-2026-10-24 |
Tomorrow
| Version | Tag | Item |
|---|---|---|
| v1 | New | Six notice templates, below, sent by a named person for anything on our side. |
| v1 | New | Incidents that last more than 30 minutes or touch a brand's data get a notice. Shorter blips do not. Proposed. |
| v1 | Changes | The writing paused toast and the paused card drop the product name and say Plays. |
| v1 | Changes | Stale connections tell the admins by email the same day, as sign in expiry already does. |
| v1 | Stays | Alerts and monitoring stay with our team. Brands hear from a person, never from an alert. |
| v2 | New | A status line in the product while an incident is open. |
The templates
| Notice | When | Plain words | Who and how | Seeti |
|---|---|---|---|---|
| Incident | Something on our side stopped working for you | <What broke>, since <time>. Your <feed, jams, briefs> are safe. We are fixing it and will write again by <time>. |
A named person, email, within the hour of knowing | None |
| Incident resolved | It is fixed | <What broke> is fixed since <time>. <What you may need to do, or nothing>. Sorry for the trouble. |
The same person, email | None |
| Maintenance | Planned downtime | On <day> from <time> to <time>, <brand> may not open. Nothing is lost. Reads and drafts wait until it is back. |
Email, 2 working days ahead | None |
| Connection lost | A tool stopped reading | <Tool> stopped reading for <brand> on <day>. Its last numbers are marked stale. Connect it again to bring them back. |
Admins, email, the same day | None |
| Change | Something new or different in the product | New: <one sentence on what changed>. <Where to find it>. |
In the product, once, and in the weekly founder note | One line allowed: “This week's marketing, ready in a few whistles.” as a sign off, never in the change itself |
| Policy change | Privacy or terms change | Our <privacy page or terms> change on <date>. What changes: <one line>. Read it here. |
Email to admins, 14 days ahead | None |
Seeti's rules for these lines
- Short sentences, often two words. Never more than two sentences per line.
- One kitchen word per line at most.
- Seeti calls the founder boss, at most once a week.
- The explanation of the whistle appears once, on the first read.
- People write apologies, privacy answers, money talk and support. Seeti stays out.
brand-directions/docs2/data/dirs.json; brand-directions/cooker/system.md
In a notice that rule means Seeti stays out of every incident, maintenance, connection and policy notice. Those are errors on our side, access or something a person must agree to.
Lines Seeti never says, in any of these:
- “I posted it for you.”
- “Your sales went up 30 percent.”
- “You missed a week. Shame.”
- “Hurry, only two hours left.”
- “Connect your accounts and I will run your ads.”
brand-directions/docs2/data/dirs.json
How we do it
When an alert or a partner shows something broke, the reader of the day decides within the hour: does it last more than 30 minutes or touch data. If yes, it gets a notice.
Find who is affected: the brands on production, and their admins.
gcloud run jobs execute brew-ops --region=asia-south1 --waitSend the incident template from hello@joinsquareup.com, signed by a first name, to each affected brand's admins.
Write again when it is fixed, with the resolved template, the same day.
For maintenance, send the template 2 working days ahead, and pick a time outside the brands' working hours.
For a policy change, update the date on the page and email admins 14 days before it takes effect.
Add a row to known issues for anything a brand may still see after the fix.
Numbers
| Metric | Definition | Where measured | State |
|---|---|---|---|
| Time to first notice | Minutes from our first alert to the first notice sent | alert email time against the notice | Proposed |
| Incidents per month | Incidents that got a notice | hello@ sent, label incident | Proposed |
| Notices resolved same day | Share of incident notices followed by a resolved notice the same day | hello@ sent | Proposed |
Open
- What counts as an incident worth a notice? Proposal: more than 30 minutes down, or anything that touches a brand's data or connections.
- Who sends notices? Proposal: Param during the design partnership, from hello@joinsquareup.com, signed with his first name.
- Do we pick a fixed maintenance window? Proposal: no fixed window; releases already roll back on their own, and planned downtime gets 2 working days notice.
- May Seeti appear in change notices? Proposal: only as the sign off line in the table, never in incidents, maintenance, connections or policy.