Knowledge base

MailerQ knowledge base›Search the MailerQ knowledge base

procedure

found: 10
Make the engine re-read the databasecriticalWritten by the HubprocedureThe engine does not notice database changes on its own; one broker message makes it re-read at once.Sign mail from a domaincriticalWritten by the HubprocedureKey, pattern, Store key, DNS — in that order, with two traps: the generated key is too short and a key without a pattern signs nothing.Set limits for a warm-up stagecriticalWritten by the HubprocedureProfile, rule, reload, read back — with the two rules that make it safe: one target per rule, and never write meaningful for a switch nobody chose.Record what a node is actually configured to doimportantprocedureSix readings that capture everything a node's behaviour depends on — and the baseline to restore it from.Make sure the telemetry has exactly one readerimportantprocedureResult queues are consumed, not read: a second reader does not duplicate the data, it splits it.Open the API on a nodeimportantWritten by the HubprocedureThe only way to get a token, and the reason a fresh node's API is closed until someone opens the console.Mail goes in, nothing comes outimportantprocedureSeven readings in order, from the broker inwards — the sequence that found both real cases on the stand.Stop the mail without losing itimportantWritten by the HubprocedureHeld mail waits rather than fails — as long as the target is named and the removal matches the fields that created it.Measure behaviour without leaving a markprocedureBaseline, local-only receiver, per-message routing, read the log, restore, compare.Drain it, stop it, and put it backWritten by the HubprocedureStop feeding it, let it finish, pause the rest — never stop the service with mail in flight.