Logging Design for Rork Apps: What to Keep and How to Redact PII

Hide PII automatically before sending

This is the most important part of the article. The more context you keep, the more PII slips in. Prepare a masking function that every value passed to meta must go through before sending.

// redact.ts — hide dangerous values before sending
const PATTERNS: { re: RegExp; mask: string }[] = [
  { re: /[\w.+-]+@[\w-]+\.[\w.-]+/g, mask: "[email]" },      // email address
  { re: /\b(?:eyJ|sk_|ghp_)[A-Za-z0-9._-]{8,}/g, mask: "[token]" }, // token-like
  { re: /\b\d{12,19}\b/g, mask: "[number]" },                 // long digit runs (card/ID)
];
 
const SENSITIVE_KEYS = ["password", "token", "email", "deviceId", "authorization"];
 
export function redact(value: unknown): unknown {
  if (typeof value === "string") {
    return PATTERNS.reduce((s, p) => s.replace(p.re, p.mask), value);
  }
  if (value && typeof value === "object") {
    const out: Record<string, unknown> = {};
    for (const [k, v] of Object.entries(value)) {
      out[k] = SENSITIVE_KEYS.includes(k.toLowerCase()) ? "[redacted]" : redact(v);
    }
    return out;
  }
  return value;
}

This function guards in two layers. Keys named email or token are replaced whole with [redacted], and any other string is scanned by regex to hide email- or token-like fragments.

Even if you carelessly pass a whole object like meta: { user }, it walks recursively and hides the contents. Nothing feels more pointless to me than scrubbing email addresses out of logs after the fact, so I strongly recommend a design that stops it mechanically at the entrance.

Switch volume by environment with log levels

In development you want to see everything. But sending every log in production inflates both bandwidth and storage cost. So cut off by log level.

// logger.ts (continued)
const ORDER: Record<Level, number> = { debug: 0, info: 1, warn: 2, error: 3 };
 
// dev: debug and up; production: warn and up only
const MIN_LEVEL: Level = __DEV__ ? "debug" : "warn";
 
export function log(level: Level, event: string, meta?: Record<string, unknown>, screen?: string) {
  if (ORDER[level] < ORDER[MIN_LEVEL]) return; // cut off
  emit({
    ts: new Date().toISOString(),
    level,
    event,
    screen,
    meta: meta ? (redact(meta) as Record<string, unknown>) : undefined,
  });
}

__DEV__ is a constant Expo switches automatically. Now dev keeps everything down to debug, while production keeps only warn and error. The fine-grained logs you need for local investigation stay out of production.

The call site simply attaches context as fields.

log("error", "save.failed", { reason: err.message, retryCount: 2 }, "NoteEditor");

Cap production cost with sampling

You want every error sent, but sending all high-frequency logs like info makes cost spike as your user base grows. So thin out only the low-importance logs to a fixed fraction.

// sampling built into the send logic
const SAMPLE_RATE: Record<Level, number> = {
  debug: 0,      // never sent in production
  info: 0.1,     // send 10%
  warn: 1,       // all
  error: 1,      // all
};
 
function shouldSend(level: Level): boolean {
  return Math.random() < SAMPLE_RATE[level];
}

In my own operation, thinning info to 10% noticeably cut the number of sends, and it was still plenty to read trends. Since warn and error go at 100%, no real investigation ever loses data. Adjusting the ratio gradually while watching user count is the realistic approach.

Which events to keep: a starting list

Logging everything makes things harder to read, not easier. Deciding the list of events to keep up front saves you hesitation. These are the four kinds I always include in a new app.

Of these, the purchase events and save.failed are set to a level that always arrives, even in production. By contrast, screen.view is info, so sampling thins it and it never strains cost.

An order for rolling the logger into an existing app

You don't need to replace every console.log at once. For an app already in production, this order is safe.

1. Drop in the two files logger.ts and redact.ts
2. Replace console.log calls around purchasing with log()
3. Replace the spots for saving and network errors
4. Migrate the rest gradually whenever you touch them

With this order, the logs for the places you most want to know about get shaped first. For events that hurt revenue yet are hard to reproduce - like an AdMob initialization failure - I recommend keeping them as error early.

The pitfall is deferring masking. Once PII lands in a log it's hard to recover, so I always build redact into the very first step.

Your next step

Start by dropping in the two files logger.ts and redact.ts, and replace console.log calls one at a time with log(). You do not need to fix them all at once. Begin around purchasing and saving, and the logs for the places you most want to know about will start to remain — with PII already hidden.

Logs are something you plant before the accident, not after. The longer you operate generated code, the more this bit of effort at the entrance ends up helping you.