Logging Standards and What Not to Log
Make logs useful and safe.
Added October 15, 2026. Written with AI assistance and checked for clarity and placeholders; not reviewed by a lawyer, accountant, clinician or other professional. How these prompts are made
The Open buttons send the prompt text as currently shown below to that site only when you click. Fill in the placeholders first.
[VERIFY] is an editorial flag, not a blank to fill. Wherever the prompt shows [VERIFY], check that item against a reliable source before you use it (what [VERIFY] means).
Write logging standards. Language and framework: [STACK]. Log tooling: [LOG_TOOLING]. Data handled: [DATA_HANDLED]. Retention needs: [RETENTION_NEEDS]. Define log levels, a structured format with fields such as time, service, request id, user id (hashed if needed), message and error, rules for context, and examples of good and bad log lines. List what must never be logged: passwords, tokens, full card numbers, health data and secrets. Provide a masking approach. Return the standard, a pull request checklist, a retention table and a test to scan logs for sensitive data. Privacy duties apply to logs [VERIFY] for [JURISDICTION]. Add a worked example of a good log line and a bad one using invented text: good, time, service checkout, request id, level warning, message payment provider timeout after 3 attempts; bad, something went wrong. Provide a table of levels and when to use each, a note on log volume and cost, and a rule that logs are searchable by request id. Remind the team to run a periodic scan for patterns that look like secrets or card numbers.
Fill in before use
Optional: type your details and the prompt above updates. Nothing is saved or sent.
Replace each bracketed placeholder with your own details, then paste into Any AI or another assistant.