DEV Community: אחיה כהן

Safari gave my blank tab no URL. My security check read that as "not yours."

אחיה כהן — Sat, 10 Oct 2026 19:28:10 +0000

I maintain safari-mcp, an MCP server that lets AI agents drive the real Safari on a Mac, logged-in sessions included. On October 7 an agent opened a blank tab, and its very next command on that tab was refused:

receipt is not valid for this origin

The agent had done everything right. It called safari_new_tab() without a URL, kept the receipt the tool returned, and passed it to safari_navigate. The tab could not be navigated, the receipt could not be rotated, and the tab could not be closed. It sat there in a named Safari profile, and nothing the agent was allowed to do could touch it.

I shipped two releases that day, and each changed one line of code. Both lines were in a guard I had built to be strict on purpose.

What a receipt is

When the safari-mcp Safari extension opens a tab for an agent, it mints an opaque receipt for that tab. Every later command carries the receipt, and before it runs anything the extension checks two things:

the receipt belongs to this tab, and
the tab is still on the origin the receipt was minted on.

The second check is the one that matters. An agent works in a browser that also holds the user's email, bank and admin panels. If a page redirects the agent's tab somewhere else, I want the agent's next evaluate refused, not run against whatever is loaded there now. To keep working, the agent has to ask for a fresh receipt on purpose (getReceipt), and the extension issues one only when it can read an http(s) origin, or about:blank, for the tab.

Fail closed. On paper, that is exactly the behavior you want.

The bug was one missing value

This is how the extension derived a tab's origin before the fix:

function _receiptOrigin(rawUrl) {
  const raw = String(rawUrl || "");
  if (raw === "about:blank") return raw;
  try {
    const parsed = new URL(raw);
    return /^https?:$/.test(parsed.protocol) ? parsed.origin : "";
  } catch {
    return "";
  }
}

A blank tab's receipt is minted on about:blank. I assumed Safari would report a blank tab's URL as about:blank. It doesn't. It leaves url off the tab entirely.

String(undefined || "") is "". new URL("") throws. The function returns "", which in this code means "no origin at all". "about:blank" !== "", so the check refused the tab's own receipt. The escape hatch called the same function, got the same "", and refused as well: Cannot issue a receipt for this tab URL.

The guard did what I built it to do. It just could not tell "this tab moved somewhere else" from "Safari didn't tell me where this tab is", and it treated both as an attack.

The sibling bug, one day earlier

On October 6 a different run left two tabs open in a named profile, both on claude.ai/new. In both cases the page itself had moved the tab, through a redirect or a login bounce. Rotation only works when the new page has an http(s) origin the extension can read; a tab that lands on a page without one, or on a page whose URL Safari doesn't show the extension, can't be rotated.

close_tab was held to the receipt's origin like every other command. The refusal suggested rotating the receipt, which was exactly what these two tabs couldn't do. Nothing could close them.

Same shape as the blank tab: a rule that is right for commands that run code in a page, applied to a command that doesn't.

Two one-line fixes

v2.22.12, the moved tab:

const allowReceiptOriginChange = type === "get_tab_receipt" || type === "close_tab";

Closing a tab runs nothing in the page, so a close now finds its tab the way getReceipt does, by the receipt rather than by the origin. Every other command stays bound to the receipt's origin, and a receipt the extension never issued still closes nothing.

v2.22.13, the blank tab:

if (!raw || raw === "about:blank") return "about:blank";

A tab Safari shows no URL for now counts as blank. A receipt minted on a web origin still takes no page command there, so a tab that went from a real site to a blank page is still refused.

What I got wrong

The origin binding was fine. Two assumptions inside it were not.

I treated "unknown" as "mismatch". A fail-closed check has at least three outcomes: it matches, it doesn't match, or the platform didn't give you enough to decide. My code folded the third into the second, because the function that read the URL returned the same empty string for "no URL reported" and for "an origin I won't trust". Once those two share a value, the guard will sooner or later lock out the owner. The fix was to decide, in code, what a missing URL means for a tab the extension created: it is blank.

I held every command to the same rule. The origin check exists to stop code from running in the wrong page. close_tab runs no code in any page. Binding it to the origin added no protection and took away the only way out. A guard should be as narrow as the harm it prevents, and every guard needs an exit that doesn't depend on the thing it guards.

A test that mocks the extension API with a tidy url: "about:blank" could never have caught the first bug. Both showed up the first time a real Safari profile did something slightly unusual, which is the reason this project drives the real browser in the first place.

If you use safari-mcp's Safari extension, both fixes live in the extension, so they take effect once you rebuild the extension app from 2.22.13 or later (the README's "Installing the Extension" section has the steps).

How do your own guards represent "I couldn't tell"? Does it get its own value, or does it quietly share one with "no"?

Cupom Chatwoot 2026: o único código real dá 5% (e onde colocar)

אחיה כהן — Tue, 06 Oct 2026 08:13:33 +0000

Aviso antes de tudo: ACHIYAVS é o meu código de afiliado do Chatwoot. Se você usar, paga 5% a menos no Chatwoot Cloud e o Chatwoot me paga uma comissão. O acordo é só esse, e é por isso que este texto existe.

Escrevo em português porque o Chatwoot é muito usado no Brasil e, quando procurei "cupom chatwoot", não achei nenhuma página em português com um código que funcione no Chatwoot Cloud. Achei o guia oficial que mostra onde digitar um cupom, uma oferta de parceiro para outro produto e listas de códigos que não existem.

O resumo

Código: ACHIYAVS
Desconto: 5% em todos os pagamentos da assinatura, mensal ou anual, segundo as regras do programa de afiliados do Chatwoot
Vale para: os planos pagos do Chatwoot Cloud (Startups, Business e Enterprise)
Não vale para: o plano gratuito Hacker e o Chatwoot auto-hospedado
Onde colocar: dentro da conta, no portal de faturamento. No cadastro não existe campo de cupom

Quanto isso dá em reais

Os preços são os da página de preços do Chatwoot em português, por agente, por mês:

Plano	Preço	Com ACHIYAVS	Diferença por agente
Startups	R$ 119	R$ 113,05	R$ 5,95 por mês
Business	R$ 249	R$ 236,55	R$ 12,45 por mês
Enterprise	R$ 639	R$ 607,05	R$ 31,95 por mês

É pouco. Numa equipe de cinco atendentes no Business, a diferença fica em R$ 62,25 por mês. Prefiro mostrar esse número pequeno e verdadeiro a prometer um desconto grande que não existe.

Onde digitar o código

O cupom entra depois que a conta já existe. O teste grátis de 15 dias vem primeiro:

Entre no Chatwoot Cloud e abra Configurações → Faturamento.
Clique em Ir para o portal de faturamento.
Escolha o plano, clique em Adicionar código promocional, digite ACHIYAVS e clique em Aplicar.
Confira o resumo do pedido antes de clicar em Enviar. O valor precisa aparecer com o desconto; se não aparecer, o código não foi aplicado.

O próprio Chatwoot tem um guia em português sobre como usar um cupom, com as telas.

Vale saber também: um link de afiliado (aquele com ?via= no final) não dá desconto nenhum sozinho. O Chatwoot registra a indicação só pelo cupom. Sem digitar o código, você paga o preço cheio.

E os cupons de 50%, 60%, 70%?

Quem procura cupom do Chatwoot encontra SINTU, PINTU, START, KUMAR, MALIK, SAVE55, GET50 e outros, prometendo de 20% a 70% de desconto. Nenhum corresponde a um desconto que o Chatwoot oferece. O programa de afiliados dá os mesmos 5% para todos (as regras estão publicadas), então um código que promete mais do que isso não é de afiliado: foi inventado, é de outro produto ou expirou há muito tempo.

E os 15% da fazer.ai?

Esse desconto existe, mas é para outro produto. A fazer.ai é a parceira oficial do Chatwoot no Brasil e oferece 15% na licença Enterprise do Chatwoot auto-hospedado. O cupom é aplicado no painel de Super Admin da sua própria instalação e vale só para operações no Brasil. Se você roda o Chatwoot no seu servidor e precisa do Enterprise, é a melhor oferta que conheço. No Chatwoot Cloud, o desconto disponível é o de afiliado, de 5%.

O que pesa mais do que o cupom

Cada plano do Chatwoot Cloud guarda o histórico de conversas por um tempo limitado e apaga o que passa disso: 30 dias no Hacker, 1 ano no Startups, 2 anos no Business e 3 anos no Enterprise. Se a sua equipe precisa consultar conversas de mais de um ano atrás, o plano certo é o Business, e a diferença de R$ 119 para R$ 249 por agente pesa muito mais do que qualquer cupom. O Business também traz voz, times e regras de automação, que o Startups não tem.

Se você prefere auto-hospedar

O Chatwoot Community Edition é gratuito e roda no seu servidor sem limite de agentes, então ali o cupom não se aplica, e nem precisa. Eu rodo Chatwoot auto-hospedado para clientes, ligado ao WhatsApp, e sei que cuidar do servidor dá trabalho. O Cloud faz sentido para quem não quer esse trabalho, e é aí que o código vale.

Última verificação: 6 de outubro de 2026, no painel de afiliados do Chatwoot, onde o ACHIYAVS aparece como "5% off on all payments". A versão em inglês desta página fica em achiya-automation.com.

n8n's Postgres Node Doesn't Send Parameters. My Dry-Run Did.

אחיה כהן — Mon, 05 Oct 2026 05:49:09 +0000

The n8n docs for the Postgres node say you can use $1, $2 and $3 in a query "to build prepared statements to use with query parameters." On September 18 I found out what that means in practice, from a failure that my own dry-run had told me couldn't happen.

The query that passed in psql

I was running an end-to-end test of a workflow I maintain that books a callback. One Postgres node stores when the callback is due, and the number of minutes comes from earlier in the flow. Sometimes there is no number, so the value is an empty string. Simplified, the node's query looked like this:

SELECT CASE
  WHEN $1 = '' THEN NULL
  ELSE make_interval(mins => $1::int)
END AS delay;

Before deploying, I had tested it in psql the way I'd test any parameterized query:

PREPARE p(text) AS
  SELECT CASE WHEN $1 = '' THEN NULL
         ELSE make_interval(mins => $1::int) END AS delay;
EXECUTE p('');   -- returns NULL

NULL, as expected. The CASE sees the empty string and never reaches the cast.

In n8n, the same node failed with invalid input syntax for type integer: "". I caught it only because I was watching that test step by step. The node had On Error set to Continue (using regular output), so the execution finished green. No retry, no alert, and no callback saved.

What n8n actually sends

The Postgres node runs on pg-promise, pinned at 11.9.1 in n8n 2.41.6, the latest stable release as I write this. pg-promise has its own formatting engine, and its README says the engine is "used by default with all query methods, unless you opt out of it entirely via option pgFormatting." n8n creates its pg-promise instance without that option.

So the values never travel as bind parameters. pg-promise escapes them and writes them into the SQL text on the client, and Postgres receives one plain string. I reproduced it this morning against a local Postgres 16.15 with the same pg-promise version:

const pgp = require('pg-promise')();
const sql = "SELECT CASE WHEN $1 = '' THEN NULL ELSE make_interval(mins => $1::int) END AS delay";
console.log(pgp.as.format(sql, ['']));

SELECT CASE WHEN '' = '' THEN NULL ELSE make_interval(mins => ''::int) END AS delay

Run that against the database and you get error 22P02, invalid input syntax for type integer: "". Send the same SQL with the same value as a real parameter (pg-promise's ParameterizedQuery) and it returns {"delay": null}, exactly like my psql test.

To be fair to n8n, the part of the docs that says it "sanitizes data in query parameters, which prevents SQL injection" holds up. The escaping is real. What changes is how Postgres types the value.

Why the CASE didn't help

$1::int on a real parameter is a run-time cast. It runs when that branch runs, and in my test that branch never ran.

''::int is something else. The Postgres docs on type casts put it this way: "A cast applied to an unadorned string literal represents the initial assignment of a type to a literal constant value." Postgres hands the string to the integer input routine while it is still analyzing the statement, before it evaluates anything. An empty string isn't valid integer input, so the statement fails before the CASE gets a say. psql points the caret right at it:

ERROR:  invalid input syntax for type integer: ""
LINE 1: ...WHEN '' = '' THEN NULL ELSE make_interval(mins => ''::int) E...
                                                             ^

The section on expression evaluation rules says it plainly: CASE "is not a cure-all," and it "does not prevent early evaluation of constant subexpressions." Once your parameters are pasted in as literals, a lot more of your query is constant than it looks.

The first half of the lesson: commas

That workflow had already burned me once through the same Query Parameters field. Earlier, a free-text value with a comma in it shifted every parameter after it. The row was saved without an error, and every value after the comma had moved one column over.

The reason is in executeQuery.operation.ts. For node version 2.5 and up (new nodes get 2.7), n8n evaluates each {{ }} in the Query Parameters field separately. If the result is an array, it takes the items one by one. Anything else becomes a string, and unless that string happens to parse as JSON, it goes through stringToArray:

return String(str)
  .split(',')
  .filter((entry) => entry)
  .map((entry) => entry.trim());

Split on commas, drop the empty pieces, trim the rest. The docs do describe the field as "a comma-separated list of values." They don't mention that the split happens after your expressions are evaluated, inside your data.

Here is what that logic does to one item. I ran a copy of those exact functions:

// Query Parameters: {{ $json.minutes }},{{ $json.note }},{{ $json.id }}
// item: { minutes: '', note: 'call back, after 5pm', id: 7 }
// values -> ["call back", "after 5pm", "7"]

The empty minutes disappeared, and the note became two values. One value vanished and one appeared, so the count still matched three placeholders and nothing failed:

SELECT 'call back'::text AS minutes, 'after 5pm'::text AS note, '7'::int AS id
-- {"minutes":"call back","note":"after 5pm","id":7}

This is the version that worries me more. The ''::int error at least stops the node. A shifted row looks fine until somebody reads it.

What I changed

1. Query Parameters is always one array expression.

{{ [ $json.minutes, $json.note, $json.id ] }}

When the whole field is one expression that returns an array, n8n uses that array as the parameter list and nothing gets split. Commas stay inside their value, and empty strings keep their position. It's also the form the n8n docs themselves use for IN (...) lists.

2. Every cast on a value that can be empty goes through NULLIF.

SELECT make_interval(mins => NULLIF($1, '')::int) AS delay;

After formatting, the empty case becomes make_interval(mins => NULLIF('', '')::int), which returns NULL, and with '15' it returns a 15-minute interval. Both ran clean in the reproduction. NULLIF turns the empty string into NULL before the cast, and NULL cast to an integer is just NULL.

3. Dry-runs test the SQL that n8n will send, not a PREPARE.

I format the query with pg-promise first and run the output inside a transaction that I roll back:

const pgp = require('pg-promise')();
console.log(pgp.as.format(sql, values)); // run it in psql between BEGIN; and ROLLBACK;

My PREPARE test was correct about a query that n8n never runs.

4. On Error → Continue stays off the node that writes the thing that matters.

The node that saves the callback now fails loudly, with Retry On Fail set to three tries. Continue is fine on a step whose failure can't hide anything downstream. On that node, it turned a failure into a quiet success.

The short version

If you write SQL in n8n's Postgres node, assume your values get pasted into the text as quoted literals, because they do. A cast on one of those literals happens when Postgres analyzes the statement, whatever branch it sits in. And a comma inside a value is a parameter boundary unless you pass an array.

I build and maintain n8n integrations for businesses at Achiya Automation, and these four rules now get checked before any Postgres node goes live.

How do you fill Query Parameters in your n8n workflows, comma string or array? If it's the comma string, have you checked what happens when one of the values contains a comma?

I filed it as a flaky test. It was a crash that try/catch can't reach.

אחיה כהן — Sun, 04 Oct 2026 08:46:12 +0000

Safari MCP, the open-source server I maintain, runs one process that owns a local bridge port. Any other instance becomes a secondary: it proxies through that primary, and if the primary goes away, it takes the port over. One test covers exactly that handoff. Start a primary, start a secondary, stop the primary, wait for the secondary to say it's listening.

On October 1 that test failed once on the Node 24 macOS runner, in a pull request run. The rerun passed, Node 20 and 22 passed, and I filed issue #140 as a CI flake. The last line I wrote there was: "Filed to track the flake and the Node version it needs; no code change in this issue yet."

Two days later the same test failed again, this time on main, a few minutes after the pull request with the same code had gone green on the same Node version.

What the secondary died of

The secondary never printed its listening line. Its stderr ended like this:

Uncaught: Error: setTypeOfService EINVAL
    at Socket.setTypeOfService (node:net:911:13)
    at writeH1 (node:internal/deps/undici/undici:8022:16)
    at Object.write (node:internal/deps/undici/undici:7758:18)
    at _resume (node:internal/deps/undici/undici:9656:54)

The code that was supposed to handle a missing primary looks like every health check you have written:

try {
  const res = await fetch(`http://127.0.0.1:${port}/proxy-check`, {
    signal: AbortSignal.timeout(2000),
  });
  // ...
} catch {
  // Nothing answers on the bridge port: the primary is gone. Take it over.
  takeOverThePort();
}

When the primary is gone, fetch() should reject and the catch should run. Instead the process ended.

Why the catch never ran

The undici that ships inside Node 24 calls socket.setTypeOfService() on every HTTP/1.1 request it writes. It's a quality-of-service hint and harmless almost everywhere. On macOS, though, the kernel refuses that option on a socket whose peer has just reset the connection. The call fails with EINVAL, and Node turns that into a thrown error.

The throw happens inside undici's write path, which runs from a socket I/O callback. Nothing there routes the error into the promise that fetch() returned, so the try/catch around await fetch() never sees it. It becomes an uncaught exception, and an uncaught exception ends the process.

So the crash needs three things at once: Node 24, macOS, and a peer that resets at the wrong moment. The test stops the primary a moment after the secondary comes up, close to the secondary's first check, which is about as close to the wrong moment as a test gets. In real use the race is rarer. But a secondary that dies exactly when it should take over is the failure the whole handoff exists to prevent.

Fixed upstream, just not in Node 24

undici fixed it in nodejs/undici#5547, "fix(h1): ignore type of service errors", released in undici 8.8.0. It skips the call when nobody asked for a type of service, and it ignores the error when the call fails. Node 24 didn't get that change.

I measured the difference by counting calls to setTypeOfService during one plain fetch() to a local server:

Node	calls per fetch
24.21.0 (newest 24.x today)	1
26.10.0	0

I'm not the only one who hit this. get-bb/bb, telomi and t3code each have a pull request for the same uncaught EINVAL.

You can't schedule a race, so fail at the boundary instead

My first instinct was to reproduce the real thing: a keep-alive server in a child process, one request to pool the socket, then a reset or a kill, then a second request onto the dead socket. Two harnesses and six timing variants on Node 24.21.0 produced zero EINVALs. The kernel race simply didn't happen on my machine, which is also why the test passed nearly every time in CI.

What worked was failing at the exact boundary instead of waiting for the race. Replace the native method with one that throws what macOS throws, then let undici's own write path call it:

import { Socket } from "node:net";
import http from "node:http";

Socket.prototype.setTypeOfService = function () {
  throw Object.assign(new Error("setTypeOfService EINVAL"), { code: "EINVAL" });
};

const server = http.createServer((req, res) => res.end("ok")).listen(0, "127.0.0.1");
await new Promise((resolve) => server.on("listening", resolve));
try {
  const res = await fetch(`http://127.0.0.1:${server.address().port}/`);
  console.log("resolved:", await res.text());
} catch (err) {
  console.log("rejected:", err.message);
}

On Node 24.21.0 that script prints neither line. It dies on the uncaught EINVAL with exit code 1, try/catch and all. On Node 26.10.0 it prints resolved: ok, because undici there never makes the call.

The fix

Upgrading Node is the real fix, but I don't pick my users' Node version, and the package supports 20 and up. So the server wraps the method once at startup and ignores EINVAL only:

export function ignoreTypeOfServiceEinval(proto) {
  const original = proto.setTypeOfService;
  if (typeof original !== "function" || original.ignoresEinval) return;
  const wrapped = function (...args) {
    try {
      return original.apply(this, args);
    } catch (err) {
      if (err?.code === "EINVAL") return this;
      throw err;
    }
  };
  wrapped.ignoresEinval = true;
  proto.setTypeOfService = wrapped;
}

With the error swallowed, undici carries on writing to a socket that's gone, the write fails the normal way, and fetch() rejects into the catch that was there all along. Any other error from the method still throws. On Node 20 and 22 the method doesn't exist, so the wrapper does nothing.

The test suite now runs the script above in a child process with the wrapper applied and asserts that the fetch resolves. I checked that the test can fail: with the wrapper replaced by a no-op, the child exits 1 on Node 24.21.0 and the test goes red. With the wrapper it passes, on my machine and on Node 24.20.0 in CI. The fix shipped in v2.22.10.

What I got wrong

The label. A test that fails because the process under test died of an uncaught exception isn't flaky in any sense that matters. The code crashed, and the test just couldn't make it crash often. "Flaky" told me to wait and see, and waiting meant the second report came from main instead of from me.

If your project runs on Node 24 on macOS and calls fetch() against something that can go away under you (a local daemon, a sidecar, a dev server you restart), search your crash logs for setTypeOfService EINVAL. It won't show up as a rejected request. It shows up as a process that isn't running anymore.

An LLM Heard Women in 71% of Our 'Male' AI Voice Replies

אחיה כהן — Wed, 30 Sep 2026 09:02:02 +0000

On 27 September a real caller on my business line spoke to our "male" AI voice using at, the feminine Hebrew "you". The voice sits at roughly 135 Hz. We had chosen it with a pitch check, and the pitch check was the mistake.

In English that would be a matter of taste. In Hebrew it's a correctness bug, because present-tense verbs carry gender. Our assistant ends its greeting with "recording and passing it on", which is מקליט ומעביר for a man and מקליטה ומעבירה for a woman. The system prompt fixes the grammatical gender, so the audio has to match it for the whole call. If it doesn't, the sentence contradicts itself.

So we measured how often each voice actually sounds like the gender it's supposed to be.

The setup

The speaker was gemini-3.8-live in he-IL, one prebuilt voice per run, thinking budget 0.
Google's Chirp 3 HD catalogue labels 16 of its voice names male. We ran 13. The other three had been recorded with feminine grammar in an earlier run, which would have confounded the test.
The script was four caller turns in Hebrew, sent as text through the realtime input (that's how our speech-to-text feeds the model in production), with the production prompt built for masculine grammar. Three separate calls per voice.
Every reply of 1.5 seconds or more was converted to what a phone line delivers, then sent to gemini-3.5-flash at temperature 0 with a single one-word question.

The conversion and the judge call, trimmed from the harness:

import audioop, io, wave
import numpy as np, soxr
from google.genai import types

def phone_wav(pcm24: bytes) -> bytes:
    """24 kHz model output -> 8 kHz mu-law round trip, i.e. what the caller hears."""
    x = np.frombuffer(pcm24, dtype=np.int16).astype(np.float32)
    x8 = soxr.resample(x, 24000, 8000, quality="HQ")
    x8 = np.clip(np.round(x8), -32768, 32767).astype(np.int16)
    x8 = audioop.ulaw2lin(audioop.lin2ulaw(x8.tobytes(), 2), 2)
    buf = io.BytesIO()
    with wave.open(buf, "wb") as w:
        w.setnchannels(1); w.setsampwidth(2); w.setframerate(8000)
        w.writeframes(x8)
    return buf.getvalue()

Q = ("Listen to the speaker in this phone recording. Does the voice sound like "
     "a man or a woman? Answer with exactly one word: man, woman, or unclear.")

async def judge(client, pcm24: bytes) -> str:
    r = await client.aio.models.generate_content(
        model="models/gemini-3.5-flash",
        contents=[types.Part.from_bytes(data=phone_wav(pcm24), mime_type="audio/wav"), Q],
        config=types.GenerateContentConfig(temperature=0))
    a = (r.text or "").strip().lower()
    return "woman" if "woman" in a else ("man" if "man" in a else "unclear")

Check for "woman" before "man". The second string is inside the first.

The results

One judging pass, run on 30 September over the recordings made on 27 September:

Voice	man	woman	unclear
Zubenelgenubi	6	6	0
Algieba	5	4	2
Sadaltager	4	8	0
Algenib	3	7	0
Alnilam	3	7	0
Charon	3	8	0
Schedar	3	7	1
Umbriel	3	8	0
Enceladus	2	8	1
Sadachbia	2	9	0
Iapetus	2	10	0
Puck	2	9	1
Fenrir	0	12	0

That's 146 replies: 103 judged female (71%), 38 male (26%), 5 unclear. Only one voice was heard as a man more often than as a woman. None of the 39 calls got through without at least one reply judged female.

These voices were speaking masculine Hebrew the whole time. If the judge were leaning on grammar, that would have pushed it toward "man", so the grammar can't explain the result.

The controls

A judge that says "woman" to everything would produce the same table, so we checked it against clips where the answer is known:

Female voices from the same model, speaking feminine grammar: 34 of 34 replies judged female.
Synthetic male callers from our test set, already at 8 kHz: judged male in 10 of 12 passes. Synthetic female callers: female in 6 of 6.
The 135 Hz voice from the opening is called Pulcherrima, and Google's catalogue labels it female. We had it speak masculine grammar anyway. It was judged male in 0 of 11 replies.

The judge can recognise a man on a phone line. It just doesn't hear one in most of these voices.

Temperature 0 didn't make the judge deterministic

This was the part I didn't expect. The same 11 Algieba clips were judged male 73% of the time on 27 September, then 45% and 55% on two passes on 30 September. One of the male control clips, an angry caller, came back man, woman, woman across three passes.

What that means in practice:

One judging pass is an anecdote. Run at least three and report the spread.
Keep known-answer controls in every run, not only in the first one.
Look at direction before magnitude. In both full passes, at least 12 of the 13 voices came out at or below 50% male. The exact percentages kept moving.

Telling the model to sound male made it worse

The obvious fix was a line in the system prompt. Translated from the Hebrew, it said: "Your voice: a man's voice, low and steady. The whole call at exactly the same pitch, even in a short sentence, a thank-you or a goodbye. Never rise to a woman's pitch."

Across the same 13 voices, the male share went from 26% without the line to 22% with it. Algieba, the only voice that had been winning, dropped to 11%. My guess, which I haven't tested, is that naming "a woman" in the instruction nudges the output toward one. We had shipped the line that afternoon and removed it the same evening.

Pitch isn't the variable

This is old news in speech science. Hillenbrand and Clark (Attention, Perception & Psychophysics, 2009) resynthesised sentences to flip the speaker's apparent sex. Shifting pitch alone, or formants alone, usually failed. Shifting both worked about 82% of the time. An F0 threshold checks one of two cues, and it's the cue our 135 Hz voice already passed while still sounding like a woman.

What we shipped

Customers now choose from 11 voices, all female. The male voices are quarantined and get re-tested whenever the model changes.
My own line keeps the one male voice, because I can live with the risk there.
Since 28 September, the greeting on customer lines is spoken by the live model itself. Before that, a separate text-to-speech model rendered it under the same voice name, and you could hear the switch between the two engines.

If you're building voice agents in a language with grammatical gender, measure the voice the way the caller will hear it, at 8 kHz rather than from the vendor's sample. Pick voices with a judge and controls, not with an F0 cutoff, and don't expect adjectives in the prompt to fix it.

I build these systems at Achiya Automation, and the service in question is Onimli, a Hebrew AI answering service for missed calls.

If you've used an LLM as a judge for audio: how many passes do you run before you believe a number, and have you seen temperature 0 flip on identical clips like this?

My 24-Month Audit Archive Was Keeping a Third of Each Day

אחיה כהן — Mon, 28 Sep 2026 08:07:46 +0000

On September 6 a disk alert fired on the server that runs my voice bots: 75% full. The culprit was /var/log/auth.log, 763 MB after five days, on a box where it normally grows about 0.7 MB a week. Nearly every line started with audispd:.

I knew why. Six days earlier I had switched on auditd's syslog plugin across the fleet so a central collector could receive the audit trail. I compressed the file, wrote the cause down, and moved on.

This morning I measured it on all eight servers. The growth turned out to be the smaller finding. The archive I built to keep audit logs for 24 months had been saving about a third of each day on my busiest server, from the week I set it up.

The setup

Eight Ubuntu 24.04 servers running auditd 3.1.2, with 22 to 25 rules each. Most rules are file watches, -w <path> -p wa, on config files and on each app's directory. Israel's data security regulations require keeping access logs for 24 months. auditd knows nothing about months. Out of the box it keeps a ring:

# /etc/audit/auditd.conf
max_log_file = 8          # MB
num_logs = 5
max_log_file_action = ROTATE

Five files of 8 MB each. When the ring is full, the oldest file is deleted. So on August 25 I added a cron job at 02:17 that forces a rotation, gzips every rotated file into /var/log/audit-archive/, and deletes archives older than 730 days. Each archive's filename carries a hash of its content, so a file that moves from audit.log.1 to audit.log.2 isn't archived twice.

On August 31 I enabled the syslog plugin:

# /etc/audit/plugins.d/syslog.conf
active = yes
args = LOG_INFO LOG_AUTHPRIV

LOG_AUTHPRIV is why the copies land in auth.log. Ubuntu's rsyslog routes auth,authpriv.* there, and logrotate keeps that file for 104 weeks.

What auth.log looks like now

The same seven days of the week, before and after August 31, on six of the eight servers. The other two are dedicated to a client, so their numbers stay out of this post.

Server	Aug 24–30	Sep 21–27	Growth	audispd share
database	2.3 MB	734 MB	×324	99.7%
website	1.4 MB	729 MB	×524	99.6%
voice	0.6 MB	275 MB	×441	99.1%
WhatsApp gateway	1.0 MB	96 MB	×101	98.0%
n8n	1.3 MB	88 MB	×70	95.5%
chatwoot	1.4 MB	1.5 MB	×1	0%

The last row is a control group: the plugin has been off on that server since September 8.

Who is writing all of this?

Not people. aureport shows which rule and which executable produced the events in the local ring:

sudo aureport --input-logs -k --summary   # events per rule key
sudo aureport --input-logs -x --summary   # events per executable

Keep --input-logs. When stdin isn't a terminal, aureport reads stdin instead of the log files and prints <no events of interest were found>. That cost me ten confused minutes this morning.

On the database server, 35,247 of the 35,659 events that matched a rule came from a single watch, -w /opt/supabase -p wa, and the executable behind 35,082 of them was postgres. The app directory contains the database's data volume, so every file Postgres opens for writing (paths like base/5/2601) becomes an audit event.

On the website, 19,120 events hit the site's watch, and rsync (14,988) and rm (4,064) account for nearly all of them. That's the deploy. One deploy last night, between 23:07 and 23:12, produced 13,151 events made of 70,516 records.

On the voice server it's the same picture: 24,687 events on the app's watch, almost all from rsync. The deploy there rewrites about 30,000 files on every run, changed or not.

One write to a watched path isn't one line. It's a SYSCALL record plus CWD, one or two PATH records and PROCTITLE, 5.4 records per event on average in that deploy. The syslog plugin also forwards the EOE (end of event) record, which auditd doesn't keep in its own log, so auth.log gets one more line per event than audit.log does.

The ring runs out before the archive runs

A 40 MB ring is fine as long as 40 MB lasts longer than the gap between archive runs. Here's how long it lasts, from aureport --input-logs -t:

database: the five files cover 13.5 hours
website: around last night's deploy, three 8 MB files filled in 3 min 48 s, then 58 s, then 17 s
chatwoot: the five files cover almost three days

The archive ran once a night. Anything that left the ring before 02:17 was deleted before anyone saved it.

So I measured the archive itself: for every archived file, the first record's timestamp and the file's mtime, merged into intervals and compared with each calendar day. Twenty-nine days, August 30 to September 27:

Server	Mean coverage	Worst day	Complete days
database	33.6%	15.0%	0 of 29
website	52.6%	9.4%	9 of 29
voice	75.0%	22.0%	16 of 29
chatwoot	94.0%	16.4%	26 of 29

On the database server, the "24-month archive" holds 234 of the last 696 hours. On the website, deploy days drop to about 10%, because a deploy late in the evening pushes everything before it out of the ring. chatwoot's three incomplete days were maintenance days: a hardening pass, a Docker update and a fleet-wide reboot.

The plugin didn't cause this. On August 30, the day before I enabled it, the database server's archive already held 28.4% of the day. Postgres had been filling the ring since the archive's first week.

The noise was the backup

The audispd lines in auth.log, the ones I spent September 6 compressing, are kept for 104 weeks. Since August 31 they have been the most complete local copy of the audit trail on these servers.

They're not a perfect copy. I counted SYSCALL records, one per event, by the timestamp inside each record, in both logs, for 23:04 to 02:00 last night:

audit.log: 19,177 events
auth.log: 18,912 events (98.6%)

The missing 1.4% left a trail too. The plugin writes to /dev/log, which on Ubuntu 24.04 is journald's socket, and journald forwards to rsyslog. During that window journald logged four Forwarding to syslog missed N messages lines, 2,789 messages in total. The journal's own copy fared worse: between 23:00 and 23:20 its rate limiter logged Suppressed … messages from auditd.service six times, 101,004 messages in all.

What I changed today

The smallest change that stops the loss is to archive more often without forcing a rotation every time. The script got a flag and a lock:

exec 9>/run/audit-archive.lock
flock -w 120 9

if [ "${1:-}" != "--no-rotate" ]; then
  /sbin/auditctl --signal rotate >/dev/null 2>&1 || pkill -USR1 auditd 2>/dev/null || true
  sleep 2
fi

The cron file got a second line:

17 2 * * * root /usr/local/bin/audit-archive.sh >/dev/null 2>&1
*/15 * * * * root /usr/local/bin/audit-archive.sh --no-rotate >/dev/null 2>&1

The nightly run still forces a rotation, so quiet servers get a daily file. The quarter-hourly run only picks up files auditd already rotated by size, which is exactly the part that used to fall off the end. The lock keeps the 02:15 and 02:17 runs from writing the same temporary file. I rolled it out to all eight servers with the old files backed up. The first run on the database server archived three files that would have been gone before tonight's 02:17.

It doesn't close every hole. A burst bigger than about 32 MB inside fifteen minutes, like two website deploys back to back, can still push a file out before the archive sees it. The durable fixes all mean writing less, and I haven't made them yet:

Stop watching the database's data directory. On August 25 I narrowed a /var/lib/docker watch to /var/lib/docker/containers for the same reason: Postgres block writes say nothing about who accessed what. The /opt/supabase watch needs the same change.
Make the deploys skip unchanged files. Thirty thousand rewritten files per deploy is an rsync problem, and auditd is only reporting it faithfully.
Give the syslog plugin its own facility, LOG_LOCAL6 with its own file, so auth.log goes back to being about logins.

Check your own servers

Three commands:

# how big is the ring?
grep -E '^(max_log_file|num_logs|max_log_file_action) ' /etc/audit/auditd.conf

# how many hours does it hold right now?
sudo aureport --input-logs -t

# who is filling it?
sudo aureport --input-logs -x --summary | head

If the second command shows fewer hours than the gap between your archive runs, your retention policy exists only in a document. I build and run automation infrastructure for small businesses at Achiya Automation, including the voice server in this post. This is the second time in five weeks that a retention number I had written down turned out to be one I had never measured.

A question for anyone who archives auditd logs for compliance: does your archive job run on rotation or on the clock, and how many hours does the ring actually hold on your busiest server? I'd especially like to hear from anyone running max_log_file_action = keep_logs with a separate mover script, and whether that held up the first time the disk got tight.

My sudo Logs Hit Nearly 10 GB. Session Count Told Me Nothing.

אחיה כהן — Thu, 24 Sep 2026 07:41:26 +0000

A disk-usage alert sent me looking at /var/log/sudo-io on a Chatwoot production box. It held 5.9 GB and was adding roughly 654 MB every week. Nothing on that server had changed. No new services, no new admins, no new cron jobs.

My first instinct was the wrong one: I assumed the server was simply busier than the others. It isn't. It runs the fewest sudo sessions of any box in the fleet that logs them.

Here is what the numbers look like, measured live across the whole fleet this morning.

The measurement

Two commands. The first counts sessions, the second measures bytes:

# how many sudo sessions were recorded
sudo find /var/log/sudo-io -name log -type f | wc -l

# how much disk those sessions occupy
sudo du -sk /var/log/sudo-io

Ten hosts in my SSH config. Only four of them have /var/log/sudo-io at all, and one of those four is dedicated to a client, so its numbers stay out of this post. The other five never had log_output enabled, and one was unreachable during the run. That inconsistency is its own finding, and I'll come back to it.

Host	Log volume	Sessions	KB per session
chatwoot	5.48 GB	16,168	356
supabase	2.33 GB	56,794	43
website	1.71 GB	14,289	126
Total	9.52 GB	87,251	114

Read the last two columns together. supabase recorded 3.5x more sudo sessions than chatwoot and produced less than half the volume. Per session, chatwoot is 8.3x heavier.

Session count and log size are not measuring the same thing, and I had been reading the wrong one.

Why bytes and sessions diverge

log_output in sudoers does not record which command ran. It records everything the command writes to its pty. A short admin command that prints two lines costs a few hundred bytes. A command that streams a file costs the size of that file.

So this:

sudo systemctl restart nginx

costs almost nothing, while this:

sudo cat /opt/chatwoot-backups/dump-2026-09-14.sql

costs the full size of the dump, every night. The dump gets written to disk a second time, into the audit log, carrying no information the original didn't already have.

That was the leak. The offsite backup job pulls a database dump every night by reading it through sudo. supabase and website already had those reads exempted in /etc/sudoers.d/iolog-exemptions. chatwoot did not. The fourth host had no exemptions file at all. Same fleet, same backup design, three different configurations — because the exemption file was written by hand on each host, one host at a time, and nothing ever checked that they matched.

The fix is an exemption, not a shutdown

The tempting fix is to turn log_output off. Don't. The recording is the point; you want to know what a human typed at 2am on a box holding customer conversations. What you don't want is a byte-for-byte copy of files you already have.

sudoers lets you carve out specific commands:

Cmnd_Alias IOLOG_EXEMPT = /usr/bin/cat /opt/chatwoot-backups/*, \
                          /usr/bin/stat /opt/chatwoot-backups/*, \
                          /usr/bin/zcat /var/log/caddy/*, \
                          /usr/bin/tail /var/log/caddy/*

Defaults!IOLOG_EXEMPT !log_output

The session still gets logged: who ran what, when. Only the byte stream is dropped.

Two things worth saying out loud about this file:

Validate before you apply it. visudo -cf /etc/sudoers.d/iolog-exemptions parses the file without installing it. A syntax error in sudoers.d can lock you out of sudo on a machine you may only reach through sudo. Keep a timestamped backup next to it.

The paths matter more than the commands. Exempting /usr/bin/cat outright would let anyone pipe any file past the audit log. Exempting cat restricted to the backup directory keeps the hole the size of the actual problem.

What ten days later looks like

I applied the exemptions across all four hosts on September 14 and measured again today, September 24.

At 654 MB/week, chatwoot should have been near 6.8 GB by now. It reads 5.48 GB. The curve turned over. Two things are doing that work together. New writes stopped, and the 60-day retention cron keeps deleting old sessions, so I'd expect the number to keep falling into mid-October as the pre-fix backlog ages out. I'm not claiming the exemption alone recovered 1.3 GB. I'm claiming the growth stopped, and that's the part I was chasing.

The part I'd actually change

The exemption fixed one symptom. The real defect is that five of ten hosts don't record sudo I/O, two of the four that do had drifted apart, and I only noticed because a disk filled up. A config that exists on some machines and not others isn't a policy, it's a habit that happened to repeat.

So the check I added isn't "is the log too big." It's this, run across the fleet:

# does this host record sudo I/O at all, and is the exemption file present?
grep -rl log_output /etc/sudoers /etc/sudoers.d/ 2>/dev/null | head -1
test -f /etc/sudoers.d/iolog-exemptions && echo "exemptions: yes" || echo "exemptions: MISSING"

Two lines, and it answers the question the disk alert was too late to ask. This is the same reasoning behind most of the fleet automation I build at achiya-automation.com — the alert that fires when a threshold breaks is always a worse version of the check that confirms a configuration is still what you think it is.

The metric to steal

If you have log_output enabled anywhere, don't look at total size and don't look at session count. Look at bytes per session:

sudo bash -c 'kb=$(du -sk /var/log/sudo-io | cut -f1); \
  n=$(find /var/log/sudo-io -name log -type f | wc -l); \
  echo "$((kb / (n>0?n:1))) KB per session across $n sessions"'

Across my fleet the number is 114 KB. Anything in that range is ordinary admin work. A host sitting at 350+ has a command streaming a file through sudo, and you can find it in one pass. A host at 43 is doing plenty of work and costing you nothing.

A question for anyone running log_output in production: what's your bytes-per-session number, and did the outlier turn out to be a backup job like mine, or something you'd never have guessed? I'm especially curious whether anyone exempts by path the way I did here, or whether you found a cleaner pattern than hand-maintained Cmnd_Alias blocks that drift between hosts.

My Monitoring Cron Never Ran Once. crontab -l Showed It Fine.

אחיה כהן — Sun, 20 Sep 2026 06:49:59 +0000

I write monitoring so I don't have to watch things by hand. So there is a special kind of dread in discovering that the monitor you installed to watch production has itself been dead since the day you installed it — and that everything you would normally check said it was fine.

This one was dead for five days. Here's the autopsy, because the failure mode is boring, extremely common, and almost invisible.

The setup

I run WhatsApp automation for businesses, and a session can silently drop: the container stays "up", the health check stays green, but the line stops receiving messages. So I built a small watchdog, waha-session-watch, that polls the sessions API every ten minutes and alerts if a line goes quiet. It runs as a dedicated unprivileged user, waha, and needs sudo for one docker call.

The crontab line looked completely ordinary:

*/10 * * * * sudo /usr/local/bin/waha-session-watch >> /opt/waha-watch/cron.log 2>&1

Install it, watch cron.log fill up, move on. Except cron.log never filled up. And I didn't notice, because I wasn't looking at cron.log. I was looking at the tool's own log, watch.log, which had plenty of recent entries. Green across the board.

Five days later a production line went dark and nothing alerted. That's when I actually went digging.

The first lie: `crontab -l`

$ crontab -l -u waha
*/10 * * * * sudo /usr/local/bin/waha-session-watch >> /opt/waha-watch/cron.log 2>&1

There it is. It's installed. crontab -l printing your line feels like proof the job runs. It is not. It only proves the line is stored. Whether cron can actually execute it is a completely separate question, and the answer here was no. Not once.

The second lie: a log full of runs

watch.log had entries. Recent ones. So the tool clearly was running... right?

2026-09-08 21:40:12  OK  all sessions healthy
2026-09-08 21:52:03  OK  all sessions healthy
2026-09-08 21:59:47  OK  all sessions healthy
2026-09-08 22:22:15  OK  all sessions healthy
2026-09-08 22:32:51  OK  all sessions healthy

Look at the minutes: :40, :52, :59, :22, :32. A */10 cron job fires at :00, :10, :20, :30, :40, on the round ten. These timestamps are ragged. Every single one of them was me, running the tool by hand from the terminal on install day to confirm it worked. Not one line in that log came from cron.

That's the trap in one sentence: a log full of successful runs is not proof of scheduled runs. Manual runs and cron runs land in the same file and look identical unless you read the clock.

The tell: one line in syslog

Here's where it actually gives itself up. I grepped the system log for the job:

$ grep CRON /var/log/syslog | grep waha
... (CRON) info (No MTA installed, discarding output)
... CMD (sudo /usr/local/bin/waha-session-watch >> /opt/waha-watch/cron.log 2>&1)

No MTA installed, discarding output.

That message is the whole case. cron ran the job, the job produced output on stderr, and cron tried to email that output to the user, because that's what cron does with anything a job writes when it can't otherwise capture it. There's no mail server, so it threw the text away. Which means: something printed an error, every ten minutes, into a void, for five days.

If your command's output were really being captured by >> cron.log, cron would have nothing to mail and this line would never appear. (No MTA installed, discarding output) sitting next to a CMD is always a sign the command printed something nobody saw. It is one of the highest-signal lines in all of syslog and almost nobody greps for it.

The root cause: who opens the `>>`

The bug is the redirect. Specifically, who opens it.

sudo /usr/local/bin/waha-session-watch >> /opt/waha-watch/cron.log 2>&1

It's intuitive to read this as "run the whole thing as root and append to the log." That's not what happens. Redirections are set up by the shell that launches the command, before the command is exec'd, and cron runs this line as the waha user. So the >> /opt/waha-watch/cron.log is opened with waha's permissions, before sudo ever runs.

And the directory:

$ ls -ld /opt/waha-watch
drwxr-xr-x 2 root root 4096 Sep  8 /opt/waha-watch

root:root, mode 755. The cron.log file didn't exist yet, and waha has no write permission in a 755 directory it doesn't own. So the shell can't create the file, the redirection fails, the shell bails out before executing sudo, and the command never runs at all. cron dutifully mails the "permission denied" to nobody.

sudo was never the problem. The unprivileged redirect target in front of it was. The privilege you granted the command is irrelevant when the shell dies setting up its plumbing first.

The fix

Anticlimactic, as these always are:

sudo touch /opt/waha-watch/cron.log
sudo chown waha:waha /opt/waha-watch/cron.log

Create the log file up front, owned by the user cron runs as. First round-numbered timestamp showed up ten minutes later and the watchdog has been real ever since. No code changed. The script was always fine.

What I actually changed

The fix took ten seconds. The lesson took five days, so it's worth more than the fix.

After installing any cron job or systemd timer, verify the first scheduled run in two independent places:

The scheduler's own record — grep CRON /var/log/syslog and confirm a CMD line with no discarding output next to it, at a round-numbered minute.
The tool's own log — an entry whose timestamp lands on the schedule, not a ragged manual one.

If those two don't agree, you have a job that is stored but not running. crontab -l is not on this list on purpose: it can only ever confirm storage.

And the redirect rule specifically: if a scheduled command redirects into a log, create that file ahead of time, owned by the user the scheduler runs as. Don't assume sudo on the command buys you anything for the >>. That file is opened by the caller, not the callee.

I build this kind of infrastructure for a living — production WhatsApp automation for Israeli businesses at Achiya Automation — and this watchdog exists precisely so a silent line doesn't go unnoticed. The irony of the watchdog itself going silent for five days is not lost on me. That's exactly why the two-place verification is now non-negotiable in my install checklist.

Your turn

What's the longest one of your "installed" monitors has been quietly dead before you noticed, and what finally gave it away? I'm collecting the tells that actually work in the wild, beyond the syslog one above. Drop yours below. #discuss

I Audited 38 Production Containers. Zero Use depends_on restart.

אחיה כהן — Thu, 17 Sep 2026 07:52:44 +0000

My n8n upgrade runbook has a line in it that I wrote by hand, sometime in 2026:

After the main container reports healthy, run docker restart n8n-docker-caddy-n8n-worker-1.

I have run that line at every version bump for months. It works. I never questioned it.

Last week I finally read the Compose specification closely enough to notice that I had hand-implemented a field that has existed since Compose 2.17.0, released in 2023. The field is depends_on.<service>.restart. My runbook is a human being standing in for one boolean.

So I went and measured how widespread the gap actually is — not in a demo repo, in the fleet that runs my clients' work.

The measurement

Eight servers, read-only, on 2026-09-17. I pulled two things from every running container: its healthcheck configuration, and the com.docker.compose.depends_on label that Compose v2 writes at create time. That label is the ground truth — it records the resolved dependency as service:condition:restart, so I didn't have to trust the YAML on disk matching what is actually running.

for c in $(docker ps --format '{{.Names}}'); do
  docker inspect "$c" --format \
    '{{index .Config.Labels "com.docker.compose.project"}}|{{.Name}}|{{index .Config.Labels "com.docker.compose.depends_on"}}'
done

Results across 38 running containers, in 14 Compose projects, on 8 servers:

	count
Containers with a healthcheck	33 / 38
Containers with any `depends_on`	7 / 38
Of those 7, using `condition: service_healthy`	7 / 7
Of those 7, using `restart: true`	0 / 7

Every dependency I had bothered to declare was declared well — all seven wait for health, none of them settle for service_started. And every single one of them ends in :false.

That trailing false is the restart flag. It means: when Compose updates the dependency, do not restart me.

The 31 containers with no depends_on at all are a separate confession, and I'll come back to them.

What depends_on actually promises

The long syntax takes three sub-options, and it is worth being precise about the scope of each:

condition: service_started — the dependency's container has been created and started. Says nothing about the process inside it.
condition: service_healthy — the dependency's healthcheck has passed. This is the one everybody reaches for.
condition: service_completed_successfully — the dependency ran to exit 0. For migration jobs and seeders.
restart: true — "Compose restarts this service after it updates the dependency service."
required: false — downgrade a missing dependency from an error to a warning.

Read the restart line again. It is scoped to Compose-controlled updates — the docker compose up -d that replaces a container with a new image. It is explicitly not about runtime crashes; your restart policy covers those.

So condition and restart answer two genuinely different questions:

condition → in what order do these containers come up the first time?
restart → what happens to me when the thing underneath me gets replaced?

A stack with condition: service_healthy everywhere and restart nowhere is fully ordered on a cold boot and fully unordered on every deploy after that. Which, on a server that boots once a year and deploys twice a month, means the feature is protecting the rare case and sitting out the common one.

Where condition alone was not enough

Two dated incidents from this fleet, both of which I originally filed as something other than what they were.

2026-07-31 — the healthy database that wasn't ready. Upgrading n8n from 2.30.6 to 2.32.6 on the queue-mode server. The worker's declared dependency reads, to this day, postgres:service_healthy,redis:service_healthy. Postgres was genuinely healthy. The worker still died — stack trace in MigrationExecutor.executePendingMigrations, then unhealthy and stuck there.

The reason is that service_healthy asked Postgres whether it was accepting connections, and Postgres honestly said yes. Nobody asked the question that mattered: has the schema been migrated to the new version yet? The main container and the worker both came up against the same database and both started running migrations. Main won. The worker crashed on a half-applied schema.

There is no healthcheck you can write on Postgres that answers "is the application's schema current", because the answer doesn't live in Postgres — it lives in whichever sibling container is doing the migrating. The fix I actually deployed was that runbook line: wait for main, restart the worker. Which is depends_on: { n8n: { condition: service_healthy, restart: true } } performed manually.

2026-09-04 — the update that kept everything running and broke one thing anyway. Docker engine 29.7.2 → 29.8.0 across the fleet. live-restore did its job: every container survived, 8→8, 5→5, 3→3. Except supabase-docker-proxy, which went unhealthy with:

ERROR Docker API proxy error error="dial unix /var/run/docker.sock: connect: connection refused"

It mounts /var/run/docker.sock. Replacing the daemon replaces the socket; the process inside kept holding the old one and never reconnected. live-restore keeps the container running — it cannot heal a client that lost its connection to the API.

The tell was ugly: docker ps showed Up 3 days (unhealthy). The uptime was true. It really had not fallen over. FailingStreak was 75, and that was the number that said when it actually broke. A docker restart fixed it in fifteen seconds.

Note what both incidents have in common. Neither container crashed. Both needed to be restarted because something underneath them changed, and in both cases the thing that noticed was a person.

The 31 with no depends_on

The honest part of the audit. Four of them are application containers in production: the Rails and Sidekiq containers of two self-hosted Chatwoot instances. They have no declared dependency on their own Postgres or Redis. On a cold boot they race, lose, crash, and get resurrected by restart: always.

That works. It has worked for a year. It is also the reason that stack's real recovery time is invisible — the recovery is a crash loop that happens to terminate, and nothing records how long it took.

While I was in there I measured the other number that deploys care about. Those Rails containers run start_period: 60s, interval: 60s, retries: 3. Add it up: a Rails container that comes back up broken can present as starting, then healthy-adjacent, for up to four minutes before Docker is willing to call it unhealthy. If your deploy script polls health to decide whether to roll back, that is the size of your blind spot.

What I changed

For the dependencies that already exist, adding one line each:

services:
  n8n-worker:
    depends_on:
      postgres:
        condition: service_healthy
      n8n:
        condition: service_healthy
        restart: true     # ← replace main, and I get restarted after it

Two changes in that block, not one. The restart: true is the field I had been simulating by hand. The new n8n entry is the fix for the 2026-07-31 incident: the worker's real dependency was never Postgres, it was whoever migrates Postgres.

Run this on your own fleet before you assume you're clean — it reads the resolved labels, not the YAML you think is deployed:

for c in $(docker ps --format '{{.Names}}'); do
  d=$(docker inspect "$c" --format '{{index .Config.Labels "com.docker.compose.depends_on"}}')
  [ -n "$d" ] && echo "$c -> $d"
done

Anything ending in :false is a container that will keep running against a dependency you just replaced.

Two caveats I'd rather state than have corrected in the comments. First, restart: true is not free — it widens each deploy, because more containers cycle. On a stack where the dependency changes often, that is the trade you are making. Second, it is still not zero-downtime; it is ordered downtime. Real zero-downtime means two versions serving at once behind a proxy, and Compose is not the tool for that. What this fixes is the cheaper, more common failure: the deploy that finishes green while something behind it is quietly talking to a socket that no longer exists.

Most of the infrastructure work at Achiya Automation looks like this — not clever, just the boring field nobody read the docs for.

The question

I'm curious whether the :false ratio is a me problem or an everyone problem. Run the loop above and post your two numbers: how many of your running containers declare depends_on at all, and how many of those end in :true?

And if you're above zero on the second number — what made you go looking? I only found it because I noticed I'd written the feature into a runbook by hand.

I Measured 27,257 MCP Connections. The p90 Session Waits 35s.

אחיה כהן — Wed, 16 Sep 2026 05:45:26 +0000

In July I wrote a 56-line shell script called mcp-optional whose entire job was to remove two MCP servers from my config.

Not fix them. Remove them.

Both were stdio servers, so each one spawns its own Node process per session. With around 13 Claude Code sessions open on a 16GB M4, that was roughly 1.4GB of duplicated RAM, which meant swap thrash, which meant a hot laptop. Disabling them by default and re-enabling on demand fixed it.

I filed that under "memory problem, solved" and stopped thinking about it.

This morning, chasing something unrelated, I started reading the MCP connection logs Claude Code leaves on disk. It turns out one of those two servers wasn't just the RAM tax. It's also the slowest thing I connect to, by a wide margin — and the reason isn't its code at all.

Here's what 35 days of logs actually say.

What I measured

Claude Code writes a JSONL log per MCP server, per session, under ~/Library/Caches/claude-cli-nodejs/<project>/mcp-logs-<server>/. Two lines matter:

Starting connection with timeout of 30000ms
Connection established with capabilities: {"hasTools":true,...}

Pair them inside one file and you get a real connection latency. I did that across every project directory on this machine:

33,599 log files, 2026-08-13 → 2026-09-16 (35 days)
38,876 connection attempts started
27,257 clean start→established pairs, across 22 servers
2,888 sessions

This is one developer's machine, not a lab. That's the point — it's the distribution you actually live in.

The headline numbers

percentile	connect time
median	582 ms
p75	1,650 ms
p90	3,678 ms
p95	6,428 ms
p99	14,049 ms

The median looks great. Under six tenths of a second — nobody would ever file a bug.

But 39% of connections take longer than a second, and the p99 is fourteen seconds. Against a client timeout of 30,000ms, the tail is not a rounding error. It's most of the way to the wall.

Cause #1: it's OAuth, not your server

This is the finding that reframed the whole thing for me. I split every connection by whether a token refresh happened inside that same connection window:

	n	median	p90
token refresh in window	748	3,170 ms	9,619 ms
no refresh	26,509	550 ms	3,400 ms

5.8× slower. Same servers, same network, same machine. The only difference is whether the client had to go get a new access token first.

Your MCP server didn't take three seconds to start. Your MCP server took 550ms to start, and an OAuth round-trip took the other 2.6 seconds while the server sat there doing nothing.

That's why "why is this server slow" is usually the wrong question. Only 2.7% of my connections hit a refresh — but that 2.7% is where a disproportionate share of the visible pain lives, because it's the path that turns a fast connection into a slow one non-deterministically. You can't reproduce it on demand, so you blame the server.

Cause #2: transport, with a twist

transport	n	median	p90
HTTP	19,894	676 ms	3,395 ms
stdio	7,363	222 ms	4,693 ms

stdio is 3× faster at the median — no surprise, there's no network. But look at p90: stdio is worse in the tail. Spawning a process has a floor of roughly nothing and a ceiling of "npm decided to do something." An HTTP server that's already running is slower on average and far more predictable.

If you're choosing a transport, that trade is the actual decision. Not "stdio is faster."

Cause #3: nobody connects to one server

Per-connection numbers hide the thing that actually costs you time, which is fan-out. Per session on this machine:

median 8 MCP servers, max 16
median total connect time: 5.9 s
p90: 35.5 s
p99: 81.8 s
33.7% of sessions spend more than 10 seconds just connecting

That p90 is the number that made me stop and re-read my own script. A third of the time I open a session, I'm waiting a meaningful fraction of a minute before the first token — not because any single server is broken, but because eight of them each drew from that fat tail and nothing amortizes.

Worst offender by median, unsurprisingly: one of the two servers I'd already disabled for RAM reasons, at 2,261 ms median and 10,413 ms at p90. I removed it in July for the wrong reason and got the right outcome.

The 29.7% nobody talks about

Of 38,876 connection attempts, 11,556 never logged an established line at all — 29.7%.

Some of that is log rotation cutting a file mid-handshake, so treat it as an upper bound rather than a failure rate. But it isn't evenly spread: a single remote connector accounts for 7,422 of them on its own. That's not noise, that's one integration failing over and over while everything upstream stays quiet about it.

The trap I almost published

My first pass had a max connect time of 119 seconds and a p99 of 14.5s, and I nearly wrote a paragraph about it.

Then I re-read the client's own log line: timeout of 30000ms. A connection cannot establish at 119 seconds if the client gives up at 30. Those samples weren't slow connections — they were a closed laptop. The wall clock kept running through sleep; the connection didn't.

So I capped every measurement at the client's declared 30s timeout and threw the rest out. That removed 24 of 27,281 samples — 0.09%. Every number above is post-cap.

I mention it because the uncapped version would have been a better story and a false one. If you run this on your own machine, cap it.

What actually helps

Count your servers before you tune any of them. Median 8, p90 35 seconds. Removing one mediocre server beats optimizing a good one.
Make heavy servers opt-in. That's all mcp-optional does — claude mcp remove by default, claude mcp add when a task needs it. It's the highest-leverage 56 lines I have written this year, and I wrote it for the wrong reason.
Look at your refresh path, not your server code. If connections are erratic rather than uniformly slow, that's the OAuth signature: 550ms most of the time, 3.2s when the token expired.
Prefer an already-running HTTP server for anything heavy. Worse median, much better p90.
Read the logs you already have. Nothing here required instrumentation. It was sitting in a cache directory the whole time.

The reason I care about any of this: at Achiya Automation I run agent tooling against real client infrastructure all day, and a 35-second session start that lands on one session in ten — with a third of them over 10 seconds — is a tax I pay dozens of times a day without ever seeing it on a bill.

One question

If you've got MCP servers configured right now — how many, and when did you last check whether you still use all of them?

I'd genuinely like to know whether median-8 is normal or whether I'm the outlier. And if you've measured a refresh-vs-no-refresh split on a different client, I want to see that number, because I only have one machine to look at.

My WhatsApp Lines Died Silently. Docker Said 'Healthy'.

אחיה כהן — Mon, 14 Sep 2026 05:47:45 +0000

At 08:33 one morning I ran GET /api/sessions against my own WhatsApp gateway and read the line I least wanted to read:

{
  "name": "session_<redacted>",
  "status": "FAILED",
  "me": { "pushName": "<business name>", "id": "<redacted>@c.us" },
  "timestamps": { "activity": "<days ago>" }
}

The last activity on that session was days old. The line had been dead for days, and every dashboard I own was green.

I run WhatsApp automation for Israeli small businesses. Each client's business number lives as a session inside a self-hosted WAHA container, which bridges their line into a CRM and a pile of n8n workflows. Several businesses, one container.

Over a few days in September, several of those lines went down. Here is what they taught me, and what I check now.

The health check was answering the wrong question

My monitor checked that the waha container was running and responsive. It was. It stayed running, responsive and healthy through every one of those outages, because a container that is perfectly happy to serve you a list of dead sessions is, by every definition Docker cares about, working.

This is the ordinary liveness-versus-readiness mistake, except the readiness that mattered was not the service's. It was the readiness of the independent sessions inside the service, each of which can fail on its own, for unrelated reasons, without the process noticing or caring.

One client's line failed one evening and I found it days later; in between, the container reported itself healthy hundreds of times.

The failure that looks like nothing at all

This failure mode is the reason I am writing this.

The gateway logs a device removed stream error when the linked device is removed from the phone, either on purpose or while someone clears out old sessions. Which of the two it was hardly matters.

What matters is what the business sees afterwards: nothing. Messages keep arriving on the owner's phone exactly as before. Customers still get replies, because a human is reading the phone. From the business's side the line looks completely, visibly fine.

Only the CRM goes blind. Only the automations stop firing. The scheduled reminders, the routing, the logging, the follow-ups — all silently not happening, behind a line that looks perfectly alive to the only person in a position to notice.

If your failure mode is invisible to the user and invisible to your health check, you do not have a monitoring gap. You have no monitoring.

You cannot always tell whose line just died

When I sat down to write the alerting, I hit a problem I had not anticipated: a dead session may not be able to tell you who it belongs to.

While a session is WORKING, /api/sessions gives you me.id (the number) and me.pushName (the business name). When a session is torn down by an unlink, those fields are wiped. The identity disappears at precisely the moment you need it to address an alert.

I want to be careful here, because I wrote this down as an absolute rule in my own notes last week and it is not one. Checking the live API this morning while drafting this post, the currently-failed line does still carry its me block, as you can see in the JSON above. So it depends on how the session died: a removed device wipes the identity, a connection-level failure does not.

Which is worse than either rule on its own, because it means you cannot depend on the field being there. The fix is the same either way: keep your own roster. My watcher rewrites a roster.json on every pass — but only from sessions currently in WORKING, because a single pass during an outage would otherwise overwrite good identity with nulls.

And you cannot recover the mapping from billing, either. I searched our accounting system for these business numbers and found none: what sits in an invoice is the owner's personal mobile, which is a different number from the business line the bot runs on. The mapping is manual, or it does not exist.

The watchdog that never ran

On 8 September I built the thing that should have caught all of this: a watcher on a ten-minute cron that diffs session states, notifies the business owner when their own line drops, and sends them a pairing code to reconnect it themselves.

I tested it. Ten test scenarios, three real bugs caught before install. I watched it run. I marked the problem solved.

It did not run once from cron until 13 September.

*/10 * * * * sudo /usr/local/bin/waha-session-watch >> /opt/waha-watch/cron.log 2>&1

/opt/waha-watch is owned by root, mode 755. The cron user is waha. The redirect is evaluated by the shell before sudo runs, as the unprivileged user, so creating cron.log failed, so the shell exited, so the command never executed at all. Cron dutifully tried to mail me the error and found no MTA installed, so it dropped it:

(CRON) info (No MTA installed, discarding output)

Five days of no monitoring, hidden behind a crontab entry that reads perfectly.

What fooled me during the install was watch.log. It had runs in it — 21:40, 21:52, 21:59, 22:22. Non-round minutes, every one of them, because they were my own manual test runs. Scheduled runs land on round minutes. I looked at a log full of evidence that the tool worked and read it as evidence that the schedule worked.

Another line fell into that exact blind window. The first genuinely scheduled run found it immediately, days late.

The fix was touch cron.log && chown waha:waha. That is the entire fix. The lesson costs more than the fix: that No MTA installed, discarding output line in syslog is never noise. It means your scheduled command printed something nobody has ever read.

What I check now

Four things changed:

Health-check the units, not the process. The container being up says nothing about the sessions inside it. Whatever your service multiplexes — tenants, sessions, connections, device links — that is the thing with a state worth alerting on.

Verify the first scheduled run, in two places. Not "is it in crontab -l", which was true and meaningless for five days. Check syslog for the CMD line, and check the tool's own log for an entry on a round minute. If a cron entry redirects to a file, create the file first, owned by the cron user.

Keep a persistent roster, written only from healthy state. Never let a failure pass overwrite identity you will need to send the alert.

Alert the person who can actually fix it. A dropped line is repaired by someone holding the phone, not by me. The watcher now messages the business owner directly with a pairing code, inside working hours, once per incident. The one-message-per-incident rule matters as much as the alert: the fastest way to get a monitoring channel ignored is to send the same thing every ten minutes.

It matters that this is WhatsApp specifically. Bezeq's 2025 Internet Report — the annual survey of Israeli internet use, published in December 2025 — notes in passing that reaching 90% WhatsApp usage in Israel took about a decade. For a small business here, that line is not a channel. It is the front door. Which is exactly why the customer-service bots running on those lines need a liveness signal independent of the phone in the owner's pocket, because the owner's pocket will never report the outage. It does not look like one from there.

Several lines, a few days, one container that never once said anything was wrong.

The question I am actually asking

I want to hear about the second category specifically — not the outage your monitoring missed, but the one where the user experience stayed completely normal while the system underneath was dead, so nobody had any reason to report it.

What was the failure, and what signal finally caught it? I am collecting these, because I suspect the honest answer for most of them is "a human noticed weeks later," and I would like to be proven wrong.

My safety guard was checked in 6 places. Nothing ever set it.

אחיה כהן — Fri, 11 Sep 2026 06:43:45 +0000

A user of my Safari MCP server — the user was me, from a scheduled run — hit a failure I could not talk my way out of.

Right after the background daemon restarted, the server opened a browser tab and handed back a capability token for it. The token is how every later command proves it is allowed to touch that tab, because the whole point of the ownership system is that the server must never act on a tab you opened. Thirty-three seconds later, the very next command was refused:

Tab safety: receipt is forged, stale, ambiguous, or not valid for this origin

Forged. By me. For a tab I had just opened, four lines earlier.

Worse, it was unrecoverable from the client side. The token could not be rotated. Switching to the tab by index was refused — "not opened by this MCP session." Closing it was refused too, which is correct, since closing is the one action you cannot undo and ownership could no longer be proven. So the tab sat there, stranded and unusable, and the agent had to reopen its work somewhere else.

Ruling things out

I had two obvious hypotheses and both died in the same session.

"A newer tab invalidates the older token." Minted a token, opened a second tab, used the first token afterwards. Worked fine.

"Switching by index corrupts the next command." Switched by index, ran a command with no token at all. Worked fine.

The one thing every failure had in common was timing. Everything opened once the daemon had been up for a couple of minutes behaved perfectly. Only the tabs created inside the restart window went bad. The first tab creation in that window took 22 seconds — the extension's background worker was still cold-starting — and that number turned out to be the entire story.

The actual mechanism

Tokens are stamped with a browser-session epoch: a random identifier that ties a token to one continuous run of the browser. If the browser restarts, the epoch rotates, and every old token is correctly rejected instead of being allowed to point at a recycled tab id. Good design. The epoch lives in session storage, which is the authority.

Here is the function that reads it:

async function _ensureBrowserSessionEpoch() {
  if (!_browserSessionStorageAvailable) {
    throw new Error("Browser session storage is unavailable; refusing durable tab authority");
  }
  if (/^[a-f0-9]{36}$/.test(_browserSessionEpoch)) return _browserSessionEpoch;
  // ... otherwise read storage, or mint and persist a new epoch
}

That last if is the problem. Once the worker has resolved an epoch into memory, it never consults storage again for the rest of its life. The cached copy is treated as the truth.

So when the epoch rotates in storage while the worker is still alive — which is exactly what a daemon restart plus an extension re-handshake does — the worker keeps stamping brand-new tokens with the old epoch, and writes them to durable storage that way. Nothing complains, because nothing is looking.

The complaint arrives later, from the one path that does read storage. When the worker eventually cold-starts, it rehydrates its tables and filters the stored tokens:

const receiptsFresh = receiptEnvelope &&
  receiptEnvelope.version === _TAB_RECEIPTS_VERSION &&
  receiptEnvelope.browserEpoch === browserEpoch && ...

Every stored record carries the stale epoch. receiptsFresh is false. The entire record array is discarded, the in-memory tables are cleared and repopulated from that empty set, and every token minted during the stale window dies at the same instant. Which is precisely what the report showed: two tabs, created five seconds apart, rejected together.

The part that actually bothers me

There was a guard for this. It just could not fire.

The code tracks a counter whose whole job is to notice that the browser-session identity changed underneath an in-flight operation. It is compared at six call sites, across the three functions that own the epoch:

2885, 2896, 2920   _ensureBrowserSessionEpoch
3043               _hydrateOwnedTabs
3075, 3095         _persistOwnedTabs

Each comparison guards a real invariant, and each one has a hand-written error message explaining what went wrong: "Browser-session identity changed during initialization." "Browser session changed during tab ownership recovery."

The variable is assigned exactly once, on line 2819:

let _browserEpochGeneration = 0;

That is the declaration. Nothing increments it. Ever.

$ grep -nE '_browserEpochGeneration\s*(\+\+|--|=[^=])' extension/background.js
2819:let _browserEpochGeneration = 0;

One hit, and it is the let. Six comparisons against a constant, plus three sites that dutifully capture it into a local first.

Why it survived review, including mine

I have been staring at this file for months, and I want to be precise about why I did not see it, because "you should have looked harder" is not a lesson anyone can apply.

The guards read as protection. Every site looks like careful concurrency code. There is a captured local, an await, and a re-check afterwards — the exact shape you are trained to pattern-match as correct. Reading for shape rather than for reachability, it passes.

Three of the six had a live half. They are compound:

if (generation !== _browserEpochGeneration || browserEpoch !== _browserSessionEpoch) {

The second clause works. So those three guards do fire, sometimes, on the epoch comparison alone — which is exactly why this bug shows up at rehydration time rather than never at all. Half of the protection was real, and the working half masked the dead half. If all six had been dead, the failure would have been louder and I would have found it sooner.

The other three, the fully dead ones, were the ones that mattered most. They sit inside _ensureBrowserSessionEpoch and have no second clause, because that function is the thing that sets the value they would compare against. Those three were supposed to catch the rotation at mint time, before a doomed token is ever handed to a caller. Instead the rotation is caught at rehydration, long after the bad tokens are in the client's hands and in durable storage.

A dead guard is worse than a missing one. A missing guard is an obvious gap. A dead guard is a gap plus a comment asserting the gap is covered, and it makes the next person to read the file — me, repeatedly — stop looking.

What would have caught it

Not a unit test. Every behavioural test over these paths passes, and would still pass with all six comparisons deleted, because the code under test never rotates the epoch. The defect is an omission, and you cannot observe an omission by exercising what is there.

This project already had one test for exactly that category, written after a different omission bug, and its own comment says so:

This is a source-level check on purpose: the failure is omission at a call site, which no behavioural test over the existing sites can see.

That test reads the source as text and asserts a property about the call sites. The same trick works here, and the rule is embarrassingly simple:

A variable that is compared must be assigned somewhere other than its declaration.

That is a grep. It is cheap enough to run over every mutable module-level variable in a file, and it would have failed loudly the day this landed. Not a linter rule I had to invent either — "assigned once, read many, never reassigned" is the shape, and the moment you write it down you realise how many state machines and generation counters and dirty-flags could rot this way without a single test turning red.

What I have not done

I have not shipped the fix.

The change itself is small: stop trusting the cached epoch, re-verify it against storage, and increment the counter when the two disagree — which lights up all six existing guards at once. I know what to type.

But this is the tab-ownership guard, and the reason it exists in the first place is that early versions of this server genuinely clicked into and closed people's tabs. The failure mode of getting the fix wrong is inverted from the current bug: today a good token is rejected rarely, in a narrow restart window. An over-eager rotation check would reject good tokens routinely. That is a strictly worse trade, and I am not making it against a theory. I want a staged reproduction that captures the epoch from both storage and the persisted record at mint time, and shows them differing, before I touch the file.

So for now the bug is open, documented, and worse than the fix — on purpose. The guard is dead either way; at least now it is dead and labelled.

If you want to look: the server is safari-mcp, and the full analysis lives on issue #105.

The question I am genuinely stuck on: how do you catch a dead guard in your own code? Grepping for compared-but-never-assigned finds this exact shape, but it is one instance of a bigger family — the if that can never be true, the catch that can never be reached, the flag nobody flips. Has anyone found a check for that family that is cheap enough to run on every commit and quiet enough that people do not start ignoring it?

DEV Community: אחיה כהן

Safari gave my blank tab no URL. My security check read that as "not yours."

What a receipt is

The bug was one missing value

The sibling bug, one day earlier

Two one-line fixes

What I got wrong

Cupom Chatwoot 2026: o único código real dá 5% (e onde colocar)

O resumo

Quanto isso dá em reais

Onde digitar o código

E os cupons de 50%, 60%, 70%?

E os 15% da fazer.ai?

O que pesa mais do que o cupom

Se você prefere auto-hospedar

n8n's Postgres Node Doesn't Send Parameters. My Dry-Run Did.

The query that passed in psql

What n8n actually sends

Why the CASE didn't help

The first half of the lesson: commas

What I changed

The short version

I filed it as a flaky test. It was a crash that try/catch can't reach.

What the secondary died of

Why the catch never ran

Fixed upstream, just not in Node 24

You can't schedule a race, so fail at the boundary instead

The fix

What I got wrong

An LLM Heard Women in 71% of Our 'Male' AI Voice Replies

The setup

The results

The controls

Temperature 0 didn't make the judge deterministic

Telling the model to sound male made it worse

Pitch isn't the variable

What we shipped

My 24-Month Audit Archive Was Keeping a Third of Each Day

The setup

What auth.log looks like now

Who is writing all of this?

The ring runs out before the archive runs

The noise was the backup

What I changed today

Check your own servers

My sudo Logs Hit Nearly 10 GB. Session Count Told Me Nothing.

The measurement

Why bytes and sessions diverge

The fix is an exemption, not a shutdown

What ten days later looks like

The part I'd actually change

The metric to steal

My Monitoring Cron Never Ran Once. crontab -l Showed It Fine.

The setup

The first lie: crontab -l

The second lie: a log full of runs

The tell: one line in syslog

The root cause: who opens the >>

The fix

What I actually changed

Your turn

I Audited 38 Production Containers. Zero Use depends_on restart.

The measurement

What depends_on actually promises

Where condition alone was not enough

The 31 with no depends_on

What I changed

The question

I Measured 27,257 MCP Connections. The p90 Session Waits 35s.

What I measured

The headline numbers

Cause #1: it's OAuth, not your server

Cause #2: transport, with a twist

Cause #3: nobody connects to one server

The 29.7% nobody talks about

The trap I almost published

What actually helps

One question

My WhatsApp Lines Died Silently. Docker Said 'Healthy'.

The health check was answering the wrong question

The first lie: `crontab -l`

The root cause: who opens the `>>`