5 Silent Bugs That Went Unnoticed For Days — And How Our Agents Finally Caught Them
Our agent network has been cataloging these in real time. Below are 5 that bit production systems hard — each caught by a specific observability pattern, and each transferable to your stack.
---
1. The 4-Day Quiet Cron
What happened: A Windows Task Scheduler job was configured to call python scripts\wiki_content_publisher.py --count 100. Someone edited the task and accidentally left the Arguments field empty — only --count 100 was being passed to Python as argv. Python happily launched, parsed the flag, found no script, exited 0. No error, no log, no failure email.
Runtime: 16 April → 20 April. Zero content generated for 4 days. Nobody noticed because the task showed "Last Run Result: 0x0" — success.
The catch: Our content agent compared last_publish_timestamp to expected cron cadence. 4 days of silence on a "daily" job triggered the alert.
What to do: For every scheduled job, log success signal content (row count, file created, bytes written), not just exit code 0. Then alert on *expected artifact absence*, not on error presence. Silent success is the worst kind of bug.
---
2. Fixed Overlay + Flex Overflow = Broken Mobile Scroll
What happened: A modal was coded as position: fixed overlay with display: flex; overflow-y: auto. Worked everywhere. Then mobile Safari users couldn't scroll the modal content. No JS error. No console warning. Just... scroll wasn't working on one device class.
The catch: A UI pattern pulled from another site's playbook: *"Fixed overlay + flex + overflow-y-auto breaks mobile Safari scroll. Nest max-h inner flex-col with its own overflow-y-auto."*
The fix:
``tsx
// Before — broken on iOS Safari
// After — nested scroll container
Why it's silent: The browser doesn't throw — scroll just doesn't register. Your only hint is user complaints. Device-class testing usually catches this, but only if someone actually tests on iOS Safari — and many teams don't.
---
3. Double-Click State Snapshot Trap
What happened: A "toggle then restore" action (e.g., apply style → print → restore style) used a simple
pattern. Then a user double-clicked rapidly. The second click fired before the first's restore completed. Its snapshot captured the mutated state as "original." Now restore restored to a mutated state. State corruption, no error.The catch: A
useRef boolean reentrancy guard:`tsx
const running = useRef(false);
async function toggleAndRestore() {
if (running.current) return; // drop concurrent invocation
running.current = true;
try {
const snap = getCurrentStyle();
mutateStyle();
await print();
restoreStyle(snap);
} finally {
running.current = false;
}
}
`Why it's silent: Every click succeeds. No exception. State just drifts over time. Users report "my formatting looks weird" days later and no repro.
---
4. Print-Isolation Via visibility:hidden = Blank PDF Pages
What happened: To hide elements in a print preview, code used
. Looks identical to display: none on screen. But in print, visibility: hidden preserves layout — empty boxes still take page space. Result: blank pages scattered through the printed PDF. Tested on screen, looked perfect. Shipped.The catch: Pattern from another site: *"Use
display: none toggle + afterprint to restore."*`css
@media print {
.no-print { display: none !important; }
}
`js
window.addEventListener('afterprint', () => {
// Cleanup — idempotent
document.querySelectorAll('.was-hidden').forEach(el => {
el.classList.remove('was-hidden');
});
});
`Bonus pattern caught:
is unreliable on iOS Safari. Solution: a 30-second setTimeout as fallback, with an idempotent cleanup guard.Why it's silent: Printing is rare. QA rarely tests it. The PDF looks "mostly right" if you glance.
---
5. The Deep-Link That Rendered Nothing
What happened: A multi-step wizard had a modal that could be deep-linked to a specific step:
/wizard?step=3. State initialization: const [step, setStep] = useState(0). Opening the deep link showed... nothing. Step 0 mapped to no component (wizard started at 1). The URL parameter was parsed but never applied to state on initial mount.The catch: A pattern from the frontend playbook: *"Deep-linking to multi-step wizard from modals must set step state explicitly; default 0 maps to nothing rendered."*
`tsx
// Before — broken for deep links
const [step, setStep] = useState(0); // always starts at 0, ignores URL// After — reads URL on mount
const [step, setStep] = useState(() => {
const urlStep = parseInt(new URLSearchParams(window.location.search).get('step') || '0');
return isNaN(urlStep) ? 1 : Math.max(1, Math.min(urlStep, MAX_STEP));
});
``Why it's silent: Click-through from the app works fine. Only bookmark / shared link / email campaign users see the blank screen. If you don't track deep-link traffic separately, you don't know.
---
The Meta-Pattern: Silence Is The Signal
All five bugs share one DNA: the absence of an error is itself the error. Traditional monitoring watches for:
None of these fired for any of the bugs above. What did fire:
The pattern: assert on outcomes, not on failures. Don't ask "did an error happen?" Ask "did the thing I expected actually happen?"
That's the category of monitoring our agents are built to do — and why silent bugs that hide from error trackers show up in our collective playbook within days.
Scan your site free — let our agents look for the silent failures you haven't noticed yet.