DEV Community: Sumit Mishra

[Boost]

Sumit Mishra — Sun, 09 Aug 2026 17:54:13 +0000

Frontend Challenge CSS Art Submission 🍲🥧

Sumit Mishra

Aug 1

समोसा — Pure CSS Comfort Food in an Indian Kitchen

#frontendchallenge #devchallenge #css #webdev

3 min read

From Infinite Slop to the Digital Casino: How AI Turned Social Media Into a Game of Chance

Sumit Mishra — Sun, 09 Aug 2026 17:48:05 +0000

We have all seen them. Bizarre, hyper-glossy images of "Shrimp Jesus," uncanny hyper-realistic videos of historical figures doing things that never happened, and a never-ending river of low-effort text and video.

Generative AI has successfully democratized creation, but in doing so, it has opened the floodgates to mass-produced digital pollution. Social media is no longer a town square or a network for human connection; it has morphed into a high-stakes slot machine.

This post explores how AI-generated content created a hyper-saturated content flood, why a lack of differentiation fuels the rise of automated media, and why scrolling today feels less like reading and more like pulling a casino lever that threatens to paralyze our minds.

1. The Standardization Trap: Why AI Rides the Wave So Easily

The rapid rise of AI-generated content is not just a technological triumph; it is a symptom of a systemic flaw in how we have built the internet. For years, content creation was heavily optimized for search engine optimization (SEO) and platform engagement algorithms.

Creators, marketers, and writers trained themselves to write with the exact same hooks, the same predictable pacing, and the same homogenized structures.

The Commoditization of Output: Because human output had already drifted toward a uniform, formulaic average, it was remarkably easy for AI models to learn, mimic, and ultimately replace it.
The Missing Differentiator: Most content lacked any real differentiation factor—no unique worldview, no specific friction, and no genuine lived experience. When content becomes entirely interchangeable, it is completely commoditized. In a digital economy, if something can be easily commoditized, an algorithm will eventually automate it to zero cost.

When 99% of feeds consist of identical commentary, recycled listicles, and visually generic synthetic media, volume becomes the only metric that matters. AI wins that race every single time.

2. The Death of Scarcity: The AI "Slop" Flood

For the entire history of the internet, content production had a natural bottleneck: human time. Writing an article, editing a video, or rendering an animation required hours of labor, thought, and skill.

Generative AI shattered that bottleneck overnight.

Zero-Cost Scaling: Anyone with an internet connection can now prompt an AI to generate hundreds of articles, dozens of short-form videos, or thousands of images in minutes.
The Economics of Volume: Content farms and individual creators realized that even if a piece of AI-generated content has a low engagement rate, mass-producing it at zero marginal cost yields a net profit through ad-revenue-sharing programs.

The result is a digital ecosystem drowning in what many call "AI slop". Feeds are saturated with redundant, hollow media designed not to communicate an idea, but to farm metrics.

3. The Content Creation Treadmill

For human creators, this flood of AI content has turned everyday publishing into an exhausting treadmill. Because algorithms favor frequency and consistency, creators are forced to compete with machines that never sleep.

When a human-made video has to fight for attention against thousands of AI-generated variations posted every second, the rules of visibility break down. To survive, creators feel pressured to adopt AI tools themselves, speeding up the treadmill even further. It is a classic race to the bottom: more content is produced, yet the average quality and meaningful signal drop drastically.

4. Social Media as a Slot Machine

This brings us to the psychological core of modern feeds: Variable Ratio Reinforcement. This is the exact mechanism that keeps people playing slot machines in casinos.

In a traditional system, input equals output (e.g., work a shift, get paid a wage). But social media algorithms run on pure unpredictability:

You post a piece of content (pull the lever).
Most of the time, it gets zero traction (the machine takes your stake).
Every once in a while, the algorithm blesses it, and you experience a massive spike of algorithmic dopamine—millions of views, thousands of followers (the jackpot).

AI has accelerated this casino dynamic for both sides of the screen. For creators, the odds of hitting the viral lottery are increasingly governed by opaque algorithmic whims, turning content creation into a digital gamble.

For consumers, the infinite, unpredictable scroll acts as a psychological trap. You pull down to refresh (pull the lever), never knowing if the next post will be boring text or a deeply engaging piece of media. This intermittent reward schedule wires the human brain to keep scrolling, searching for that next hit of novelty amidst the sea of slop.

5. The Real Threat: Algorithms That Paralyze Our Minds

We spent decades watching science fiction warn us about physical, Terminator-style robots overtaking humanity, completely missing the silent invasion happening right inside our screens.

Algorithms do not need to conquer us with physical force because they have learned how to bypass our cognitive defenses entirely. They operate like a neurological software patch, exploiting the deepest vulnerabilities of human psychology:

Hijacking Dopamine Pathways: By feeding our brains an unpredictable stream of outrage, novelty, and validation, algorithms rewire our attention spans. They turn us into passive consumers who struggle to sit with silence, deep thought, or long-form focus.
The Paralysis of Choice and Noise: When you flood the mind with an endless sea of low-differentiating, synthetic content, cognitive overload sets in. You are constantly processing information, but because most of it is empty noise, your critical thinking capabilities become paralyzed. You are mentally exhausted without having actually learned or experienced anything of substance.
Outsourcing Agency: The scariest part of algorithmic paralysis is how seamlessly it replaces our own internal decision-making. What to watch, what to buy, what to feel outraged about, and what to think—these are increasingly queued up for us by a recommendation engine designed to maximize engagement rather than human well-being.

6. Conclusion: Rewiring Our Minds and Platforms

Moving past the era of automated digital pollution requires more than just venting frustration or blindly hating AI-generated tools. The solution demands a fundamental shift in our collective psychology. Instead of passively consuming endless feeds out of habit, we need to treat online media with intentionality—reserving our attention strictly for dynamic facts, real-world developments, and genuine human insights rather than hollow volume.

At the same time, the burden cannot fall solely on the consumer. Platforms must step up by implementing strict structural benchmarks and basic quality checks to filter out uncurated, mass-produced noise. Until platforms are forced to establish quality floors that reward substance over sheer output, the digital casino will keep spinning.

Protecting ourselves from this cognitive paralysis means building intentional mental firewalls, treating our attention as a finite, non-renewable resource, and fiercely guarding the quiet spaces where real, independent thought actually happens.

I Built a Noodle Shop Landing Page That Throws Food at Your Screen 🍜

Sumit Mishra — Tue, 04 Aug 2026 11:26:08 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing

What I Built

I built SLURP! — Tastiest Noodles on the Planet, a single-page landing page for an imaginary noodle shop. The comfort food theme is ramen and noodle bowls — warm, slurpy, a little chaotic — and I leaned into that with copy, color, and interactions that feel cozy and playful.

The hook: Chef Marco is so confident in his noodles that he literally throws a bowl at your screen. The hero CTA is "TRY AND CATCH THIS! 🍜" — miss the catch, get roasted, then explore the rest of the shop.

What's on the page:

Noodle Splash Hero — full-screen SVG + CSS animation (sauce smears, flying noodle clusters, garnishes, a frosted-glass "SPLAAAT!" modal). Each replay seeds random extra strands in JavaScript so the splatter feels slightly different every time.
The Noodle Vault — six signature bowls in a CollectUI-inspired card grid (Dragon Breath Chili Oil, Midnight Tonkotsu, Garlic Butter Dan Dan, Bombay Street Manchow, Golden Curry Udon, Peanut Crunch Yakisoba) with category filter chips and wavy noodle-strand SVG borders generated at runtime.
Build Your Bowl — live CSS plate preview (broth color, thick/thin/broth-only noodles, six toppings). No image swaps — just custom properties, positioned elements, and steam keyframes. Hit "Lock In My Plate", then "Buy This Bowl" — it drops into the cart with a generated name.
Galactic Slurp — story section with a Three.js spinning globe, alien rider, and twinkling stars (static fallback for prefers-reduced-motion and WebGL failures).
Pan India Store Finder — 15 kitchens across 12 cities, searchable by city, area, or pincode, with Google Maps directions.
Slurp Squad — eight fake testimonials from regulars who also failed to catch the noodles.
Social Feed Preview — Reels/Stories/TikTok-style cards using the same self-hosted bowl photos (platform buttons are visual-only demos).
Gift a Bowl — send-a-bowl flow with searchable delivery-location and preset-message pickers, live gift card preview.
Slurp Support — contact channel cards (phone, WhatsApp, email, order help), seven-item FAQ accordion with peacock show-more, quick links to stores/gift/checkout, wired into desktop nav.
Desktop section nav — frosted-glass bar, pill-shaped link track with grouped dividers, orange-gradient active states, and a scroll-progress indicator.
CollectUI Checkout Flow — Alpine.js cart with sticky bar, mobile bottom sheet, and a full client-side order flow.

Stack: one index.html file — HTML, Tailwind CSS (CDN), Alpine.js 3.14, Three.js 0.172, vanilla JS, Lucide icons, Chewy font. No build step. All images self-hosted in /assets. MIT licensed.

Source: github.com/Sumit884-byte/tasty_noodles

Demo

Live site: tastynoodles.vercel.app

Click TRY AND CATCH THIS! on the hero — that's the centerpiece interaction. Append ?splash to the URL if you want to land directly in the splatter overlay.

Scroll demo — full page top to bottom, every section (~57s):

Watch scroll demo (MP4)

Interaction tour (with voiceover)

I recorded a ~111s desktop walkthrough (111.1s) — narrated clicks through the main Alpine.js interactions: hero splash, nav scroll-spy, peacock show-more, bowl builder, gift pickers, FAQ accordion, and checkout.

Watch interaction tour (MP4)

Interactions demonstrated:

Hero splash — TRY AND CATCH THIS! triggers the SVG/CSS splatter overlay; dismiss with Wipe Screen & Place Order
Desktop nav pills — frosted pill track with scroll-spy active states
Peacock show-more — menu vault expands from 3 → 6 bowls in place
Build Your Bowl — broth/noodle/topping chips → Lock In My Plate → Buy This Bowl (cart bump)
Gift pickers — searchable delivery-location and preset-message dropdowns with live card preview
Support FAQ — accordion expand + peacock show-more for hidden questions
Checkout — cart summary after items are added

Screenshots (hero through checkout — current layout):

Links:

🍜 Live demo: tastynoodles.vercel.app
📦 Source: github.com/Sumit884-byte/tasty_noodles

Journey

Why noodles?

The DEV Frontend Challenge prompt was comfort food — not "a nice restaurant site," but something that makes you hungry just thinking about it. Noodles felt right: warm broth, slurping sounds, late-night cravings. I wanted the page to feel like a brand, not a template — chunky typography, an amber/orange/stone palette, and interactions that reward curiosity.

Process

I started with the splash hero because it set the tone. Pure SVG + CSS — no canvas, no video, no Lottie. stroke-dashoffset for smears and strands, staggered keyframes for clusters and garnishes, JavaScript to seed random extra strands on each replay.

From there I built outward: menu cards with runtime-generated wavy SVG borders, the CSS-only bowl builder (my favorite section technically — a well-structured DOM + custom properties replaced a lot of image-swap logic), then the Three.js globe with performance guardrails (IntersectionObserver to pause off-screen, visibilitychange for hidden tabs, adaptive geometry, pixelRatio cap, static fallback for reduced motion).

Alpine.js became the app's brain — one slurpApp() component handles cart, custom plate builder, store locator, menu filtering, splash overlay, mobile nav, gift flow, support FAQ, and checkout. I baked accessibility in from the start: skip link, splash dialog with focus management, aria-pressed on builder chips, prefers-reduced-motion disabling splash/globe/steam animations, semantic landmarks, lazy-loaded images with explicit dimensions.

Later passes added Slurp Support — contact cards, accordion FAQ, peacock show-more, quick links — and tightened the Gift a Bowl pickers. Nested @click.outside handlers were closing delivery-location and preset-message dropdowns before you could pick an option; scoping each picker (and @click.stop on the search inputs) fixed it, and a clearer giftPresetItem getter made the preset dropdown label behave.

The desktop upper nav got a full polish pass: frosted-glass bar, pill-shaped link track with grouped dividers, orange-gradient active states, and a scroll-progress bar. That redesign surfaced an Alpine gotcha — x-for with multiple root nodes (divider span + link) only rendered the dividers. Wrapping each iteration in a single .site-nav__item fixed it, along with contrast, hover, and overflow tweaks at the 1024px breakpoint.

How responsivity is designed

Responsivity on SLURP! is not a bolted-on @media pass at the end — I designed it into navigation, layout grids, scroll behavior, and motion from the start. The page uses Tailwind's default breakpoints (sm 640px, md 768px, lg 1024px, xl 1280px), but the primary split is lg (1024px): below that you're in touch-first mode; above it you're in desktop mode.

Navigation: bottom tabs vs pill track

On mobile and tablet (max-width: 1023px):

The frosted top bar keeps logo, locale picker, and a hamburger drawer (full section list + locale chips).
Section navigation moves to a fixed bottom tab bar — five icons: Dare, Menu, Build, Gift, Cart — with a wavy noodle SVG divider and env(safe-area-inset-bottom) padding for notched phones.
The floating checkout bar sits above the tab bar (bottom: calc(4.875rem + safe-area)), never behind it.
body gets bottom padding so content isn't hidden under the chrome; when the cart bar is visible, padding doubles.

On desktop (lg: / min-width: 1024px):

Hamburger and bottom tab bar hide (lg:hidden).
A pill-shaped nav track appears in the header (hidden lg:block) — frosted inner track, grouped dividers between section clusters, orange-gradient active link states, and a scroll-progress bar.
The track scrolls horizontally when the viewport is tight (1024–1279px): link font-size and padding compress, checkout button becomes icon-only, and locale picker label hides until xl.
Checkout moves into the header; the "Checkout" label appears at xl.

Scroll offsets are wired through CSS variables on :root:

--site-header-offset: 3.5rem;   /* mobile */
--site-bottom-offset: 4.875rem; /* mobile tab bar */
/* at 1024px+: header 5rem, bottom 0 */

scroll-padding-top and .section-scroll-target { scroll-margin-top } keep anchor jumps from landing under fixed chrome.

Layout grids and section patterns

Section	Mobile	`md` (768px)	`lg` (1024px)
Menu cards	1 col	2 col	3 col
Gift a Bowl	stacked	—	2-col grid + sticky preview
Store results	1 col	2 col	—
Social share cards	1 col	2 col (`sm`)	4 col
Build Your Bowl	stacked	2 col	—
Learn section	horizontal step strip	—	sticky step list

Gift layout: .gift-layout is a single-column grid on mobile; at lg it becomes grid-template-columns: 1.05fr 0.95fr with .gift-preview-wrap { position: sticky; top: 6rem }. Form fields use sm:grid-cols-2 for To/From name pairs.

Store finder: search row stacks vertically until sm, then row-aligns; decorative elephant SVGs are display: none until md. Store decor animations scale down or hide on small screens to reduce visual noise.

Menu cards: CollectUI-style grid with horizontal-scrolling category filter pills (menu-cat-scroll, scrollbar hidden). Cards use runtime wavy SVG borders via attachNoodleFrame().

Overflow and progressive disclosure

Instead of infinite scroll, long lists use peacock show-more buttons (section-show-more-btn) with Alpine visibleSlice() — initial limits of 3–4 items per section (menu, stores, reviews, spread, slurp-code, checkout, support FAQ). Tap expands in place; no route change, no pagination component.

Other intentional overflow:

Desktop nav track: overflow-x: auto with edge fade masks.
Learn step strip on tablet: horizontal scroll + scroll-snap-type: x mandatory.
Category pills: overflow-x-auto with hidden scrollbars.

Motion, cursors, and locale

prefers-reduced-motion: reduce disables splash animations, globe spin, steam keyframes, store decoration animations, nav hover transforms, and chopstick card ornaments. JavaScript checks matchMedia('(prefers-reduced-motion: reduce)') before confetti, splash replay, and Three.js init — static fallback for the globe.

Chopstick theme (body.chopstick-theme): custom noodle cursors apply only under @media (pointer: fine) — touch users keep the system cursor. Section-scoped accent colors via body[data-section="…"] { --chopstick-accent }. Active nav states show crossed-chopstick icons (inline on drawer links, overlay on desktop pills, above icon on mobile bottom nav).

Locale picker: compact toggle in the header; full locale chip row in the mobile drawer. A floating locale-suggestion banner uses max-width: calc(100vw - 1.5rem) and repositions at md. Between 1024–1279px the picker label hides to save header space.

Checkout UX across breakpoints

The CollectUI-style flow uses a floating checkout bar when items are in cart — centered, max-width 24rem, with optional inline qty stepper for single-item carts. On mobile it floats above the bottom nav; on desktop it sits at bottom: 1rem with no body padding conflict. The checkout section itself is a centered max-w-2xl card with peacock show-more for long cart lists.

What I'm proud of

The splash animation — elaborate, replayable, and still pure SVG/CSS
The CSS bowl preview — instant, lightweight, infinitely recombinable
Wavy SVG card borders via attachNoodleFrame() — micro-detail that makes the UI feel designed
Progressive enhancement for motion and WebGL — fun features that don't punish users who prefer reduced motion or lack WebGL
Slurp Support — contact cards and FAQ that feel on-brand, not a generic help-desk widget pasted onto a landing page
The desktop nav — frosted glass, pill track, scroll progress, and a real Alpine x-for debugging story
Shipping everything in one file you can open locally without explaining npm

What I learned

Commit to the joke, but ship real craft. The copy is silly; underneath there's form validation, accessible modals, performance-conscious 3D, and responsive layouts.

CSS can do more than I thought. The bowl preview taught me that custom properties + keyframes can replace a lot of asset-heavy UI logic.

Constraints spark creativity. "Comfort food" pushed me toward warmth and interactivity instead of a generic SaaS layout.

Single-file projects are underrated. For a challenge submission or portfolio piece, one index.html felt like a superpower.

What's next?

This was a challenge submission, not a production restaurant platform — but there's room to grow:

Extract the splash animation into a reusable Web Component
Add sound effects (with mute toggle)
Wire up real social links if SLURP! ever becomes a real brand
India wireframe map with store pins — a sketch-style outline of the country with clickable markers for each kitchen, tied into the existing store finder
Peacock feather expansion on show-more — peacock buttons already reveal extra menu cards, testimonials, and support FAQs; next up is a feather-fan unfold animation on click, so expanding a section feels like the bird opening its tail

For now, I'm happy with what I shipped: a page that makes people smile, teaches a few frontend tricks, and proves that comfort food deserves better than a stock photo and an "Order Now" button.

If you're participating in the challenge — or you've built something fun for it already — drop a link in the comments. I want to see your comfort food takes.

And if you try to catch the noodles... good luck. Chef Marco doesn't believe in you. 🍜

Built with too much chili oil and not enough sleep. MIT licensed — see LICENSE.

समोसा — Pure CSS Comfort Food in an Indian Kitchen

Sumit Mishra — Sat, 01 Aug 2026 14:20:12 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art.

For me, comfort food means samosas — crispy, golden, still warm from the fryer, with mint and tamarind chutney on the side. Rainy evenings, chai breaks, street stalls, family gatherings: a samosa shows up in all of them.

This project recreates that feeling with no images, no SVG, and no JavaScript — only HTML and CSS.

Demo

Try it live on CodePen — kitchen scene, cooking steps, and the full animation loop:

CodePen: https://codepen.io/sumit_mishra_cb22d5be5f02/pen/jEyXMLo

Live demo: https://css-samosa-kitchen.vercel.app

Open index.html locally, or deploy the folder to any static host.

What you're looking at

Panel 1 — Kitchen scene

A flat illustration of a home kitchen:

Wall & backsplash — cream plaster, subway tiles, red/green border bands, warm window light
Props — matkas on the wall, spice jars, masala dabba, hanging ladle, chakla-belan, chai glass, folded napkin
The plate — oval rim, inner ring, shadow, lemon wedge, coriander, pickle slice
Three samosas — clip-path triangles with fold lines, crimped bases, oil blisters, side shading
Chutney — semicircle sauce in katori bowls on tiny saucer plates (mint green + tamarind red)
Details — rising steam, crumbs, oil spots, diagram-style labels, rain on the kitchen window
Bitten samosa — one samosa with a potato filling cross-section, as if someone already took a bite

A 7-second CSS loop brings samosas and chutney onto the plate with staggered entrance keyframes, a dip-into-chutney-and-bite beat on the left samosa, screen-shatter effects, and steam on a shared timeline.

Panel 2 — Cooking steps

Scroll down for a 5-step cooking illustration (knead → fill → fold → fry → serve) — also built entirely in CSS with a 25-second step cycle. The final serve frame mirrors Panel 1: same oval plate, katori chutney bowls, and golden samosa tones.

The title uses Yatra One for Devanagari (समोसा) with an English subtitle — the only external assets are Google Fonts.

Inspiration

I grew up treating samosas as the default answer to "what should we eat?" They are street food and home food at once. I wanted the page to feel like a cross-section of an Indian kitchen — not a dark 3D render, but the kind of warm, labeled illustration you'd see in a cookbook margin.

Technical highlights

Samosa shape

Each samosa uses clip-path: polygon() for the triangle, layered linear and radial gradients for the fried crust, a vertical fold line, and a repeating gradient crimp at the base.

Chutney bowls

Chutney is a semicircle fill inside a CSS katori (open bowl curve), sitting on a small oval saucer — so it reads as sauce in a dish, not a flat green/red dot.

Kitchen background

Every prop is divs and pseudo-elements: window panes on a grid, shelf boards, jar lids, a brass-toned ladle, wood-grain table stripes. No icon fonts, no PNGs.

Animation

Entrance keyframes, dip-and-bite motion, screen shake, crack lines, and glass-shatter shards are pure CSS. prefers-reduced-motion is respected throughout.

Journey / lessons

Placement matters. Chutney looked wrong until the bowls moved inside the plate container and sat at the correct inset — percentages relative to the plate, not the full viewport.
Layer order tricks you. A white "bowl rim" div on top of the sauce looked like a lid; swapping to a border on the sauce fixed it instantly.
Reference helps. A flat illustration reference pushed the scene from moody 3D toward a clearer, warmer kitchen diagram — which fit the comfort-food brief better.

What I'd do next: ~~rain streaks on the kitchen window~~ ✓ added — overcast sky, falling streaks, and glass-pane sheen for the rainy-evening mood in the intro.

Stack

HTML + CSS only
Google Fonts: Yatra One, Hind

License: MIT — use and remix freely.

Tags for DEV: #frontendchallenge #devchallenge #css #cssart

The Modern Developer Playbook: Building, Shipping, and Scaling in Public

Sumit Mishra — Fri, 31 Jul 2026 06:05:53 +0000

The Modern Developer Playbook: Building, Shipping, and Scaling in Public

In software engineering, traditional credentials like degrees, resume buzzwords, and isolated side projects no longer guarantee a direct path into high-impact roles. The developer ecosystem has shifted heavily toward proof of execution: tangible evidence that you can build, deploy, optimize, and communicate real software under production constraints.

Becoming an exceptional developer in today's landscape requires balancing technical depth, public visibility, system design, and execution discipline.

Here is the complete blueprint for executing this strategy.

1. Proof of Execution: Build in Public and Focus on Impact

Building software in isolation limits your feedback loops and hides your problem-solving process. Shifting toward public execution turns your work into an organic career magnet.

A. The One Gigantic Project Strategy

Instead of scattering your energy across five small tutorial-level projects, build one massive, production-grade flagship product. A single high-complexity system demonstrates real-world architecture, depth, and persistence far better than multiple shallow repositories.

Developer Tooling: End-to-end CLI platforms, automated release engines, or custom language parsers.
Data Pipelines: OCR and document indexing pipelines, real-time analytics platforms, or high-throughput stream processors.
Specialized Utilities: Hybrid volatility engines, semantic search protocols, or enterprise API gateways.

B. Document the Engineering Process

Documenting your journey publicizes your technical decision-making and consistency:

Public Development Logs: Share short weekly logs covering architecture choices, performance trade-offs, and technical roadblocks.
Show Your Work: Share visual demos, system diagrams, benchmarking results, or performance graphs to highlight execution quality.
Transparent Post-Mortems: Write down what broke during production deployments, why it failed, and how you fixed it.

2. High-Trust Technical Blogging: Screenshots, Videos, and Code

Abstract code snippets and textual claims are easy to fabricate; visual proof generates immediate trust. Writing technical deep-dives paired with unedited UI screenshots, architecture diagrams, and brief terminal recordings proves your software operates in real runtime environments.

A. The High-Trust Technical Post Architecture

Every deep-dive article on your blog or platform should follow a clear structure to build credibility:

+-----------------------------------------------------------------------------------+
|                        HIGH-TRUST TECHNICAL BLOG FORMAT                           |
+-----------------------------------------------------------------------------------+
|  1. THE PROBLEM        --> State the performance bottleneck, error, or system goal. |
|  2. VISUAL EVIDENCE    --> Provide runtime terminal logs or screen recordings.    |
|  3. SYSTEM ARCHITECTURE--> Embed clean diagrams (e.g., Excalidraw, Mermaid).      |
|  4. CODE & EXPLANATION --> Show precise, syntax-highlighted production code.      |
|  5. BENCHMARKS         --> Share before/after metrics (profiler graphs, latency). |
+-----------------------------------------------------------------------------------+

B. Visual Proof Assets

Annotated Screenshots: Use clean, uncropped UI screenshots with highlighted regions to demonstrate edge cases, memory profiles, or browser DEV tools network tabs.
Terminal & Interface Screen Recordings: Embed 10–30 second GIFs or video loops showing your application in motion, CLI flags executing, or real-time streaming data handling live payloads.
Interactive Code Snippets: Accompany visuals with runnable code blocks rather than static text, allowing readers to verify logic locally.

3. The Distribution Framework: Amplifying Your Proof of Work

Your distribution efforts must scale in direct proportion to your execution effort. Building a world-class project in silence yields zero leverage. If you spend weeks engineering a system, spend equal energy distributing it across software communities.

+-----------------------------------------------------------------------------------+
|                            THE DISTRIBUTION FLYWHEEL                              |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|  [ CORE BUILD ]  --->  [ DEMO & VISUALS ]  --->  [ MULTI-PLATFORM DISTRIBUTION ]  |
|  (Flagship App)        (Video/Screenshots)       (X, LinkedIn, Reddit, Hashnode)  |
|         ^                                                                   |     |
|         |                                                                   v     |
|         +------------------ [ FEEDBACK & TRACTION ] <-----------------------+     |
|                                                                                   |
+-----------------------------------------------------------------------------------+

A. Tailoring Content Across Platforms

Different platforms require distinct storytelling angles for the same underlying piece of engineering:

X (Twitter): Post short, visual-first updates. Focus on code snippets, UI polish, speed benchmarks, and quick terminal video recordings.
LinkedIn: Share high-level engineering decisions, architectural trade-offs, project milestones, embedded blog posts, and career takeaways.
Reddit & Tech Communities: Share technical write-ups in subreddits (e.g., r/programming, r/webdev, r/Python) and platforms like Hacker News, Hashnode, or Dev.to. Focus on problem-solving, performance gains, screenshots of benchmarks, and asking for code reviews rather than self-promotion.

B. Leverage Distribution for Flagship Projects

Focusing on one major project makes distribution exponentially easier:

You create a unified narrative around a single product over months rather than resetting your audience's attention with a new toy project every week.
You can write deep-dive blog posts into individual sub-systems (e.g., "How I reduced database query latency by 40% in [Project Name]" featuring profiler screenshots).
You build genuine brand equity and domain authority around one core subject.

4. Choosing Your Sub-Career Focus

Spreading yourself across too many domains dilutes your expertise. Select a primary domain to focus your deep-work hours and tailor your portfolio.

Focus Area	Core Focus Areas	Key Output & Proof of Work	Primary Tech Stack
Backend & Systems	API design, concurrency, database query optimization, caching, microservices, and system reliability.	Fast REST/gRPC services, custom ORM tools, search engines, and real-time data pipelines.	Python, Go, Node.js, PostgreSQL, Redis, Docker
Frontend & UI/UX	Client-side performance, state management, render optimizations, component architecture, and accessibility.	Polished web applications, UI component design systems, and responsive dashboards.	TypeScript, React, Next.js, Tailwind CSS, shadcn/ui
Full-Stack	End-to-end product delivery, fast prototyping, integrating complex frontends with scalable APIs.	Production SaaS applications, automated web portals, and feature-complete tools.	Next.js, FastAPI/Node, PostgreSQL, Prisma/Drizzle
AI / Data Engineering	Vector indexing, retrieval-augmented generation (RAG), model fine-tuning, and data processing.	Custom semantic search engines, sentiment/volatility analyzers, and automated data pipelines.	Python, PyTorch, LangChain, Qdrant/Pinecone, Pandas

Choose the path that aligns with the problems you enjoy solving daily.

5. The Open Source Advantage: Bounties, Grants, and Contributions

Open source acts as a global codebase where you can work alongside experienced engineers.

A. Targeted Codebase Contributions

Start by inspecting open-source tools you rely on daily.
Review open pull requests to learn repository conventions, code style guidelines, and testing requirements before submitting code.
Address issues labeled good first issue, help wanted, or work on improving documentation and automated tests.

B. Grants and Bounties

Monetized Open Source: Platforms like Algora, Gitcoin, and Immunefi offer financial bounties for resolving issues, building feature requests, or finding security vulnerabilities.
Ecosystem Grants: Many open foundations and companies award non-dilutive grants to independent builders contributing to core open-source infrastructure or developer tools.

6. Strategic Problem Solving (DSA Pattern Recognition)

Data Structures & Algorithms (DSA) remain a primary technical filter during engineering interviews. Treat DSA as pattern recognition rather than rote memorization.

                  +-----------------------------------+
                  |      MASTERING DSA PATTERNS       |
                  +-----------------------------------+
                                    |
          +-------------------------+-------------------------+
          |                                                   |
+-------------------+                               +-------------------+
|   CORE PATTERNS   |                               | LANGUAGE SELECTION|
+-------------------+                               +-------------------+
| • Two Pointers    |                               | Python: Ideal for |
| • Sliding Window  |                               | speed, clean      |
| • Prefix Sums     |                               | syntax, and built-|
| • Binary Search   |                               | in structures.    |
| • BFS / DFS       |                               +-------------------+
| • Dynamic Prog.   |                                         |
+-------------------+                                         |
          |                                                   |
          +-------------------------+-------------------------+
                                    |
                  +-----------------------------------+
                  |       STRUCTURED PROBLEM SETS     |
                  +-----------------------------------+
                  | Focus on 100-150 targeted problems |
                  | (e.g., NeetCode 150, Blind 75)    |
                  +-----------------------------------+

Time Complexity Reference Guide

Ensure you analyze the asymptotic complexity for every problem solved:

Pattern / Algorithm	Average Time Complexity	Space Complexity
Hash Table Lookup	O(1)	O(N)
Binary Search	O(log N)	O(1)
Two Pointers / Sliding Window	O(N)	O(1)
Tree/Graph Traversal (BFS/DFS)	O(V + E)	O(V)
Sorting (MergeSort, QuickSort)	O(N log N)	O(N) or O(log N)
Dynamic Programming (Grid/Knapsack)	O(N × M)	O(N × M)

7. Execution Strategy and Time Allocation

To prevent burnout while balancing product development, distribution, DSA, and career opportunities, maintain a structured schedule:

+-----------------------------------------------------------------------------------+
|                            DAILY EXECUTION PIPELINE                               |
+----------------------------------------+------------------------------------------+
|         BLOCK 1: DSA & WARMUP          |        BLOCK 2: DEEP WORK & BUILDING     |
|              (60–90 Mins)              |               (2–3 Hours)                |
+----------------------------------------+------------------------------------------+
| • Solve 1-2 targeted pattern problems  | • Focus on the single flagship project   |
| • Focus on time/space complexity       | • Optimize performance and write tests   |
| • Practice explaining solutions aloud  | • Draft visual technical blog posts      |
+----------------------------------------+------------------------------------------+

Action Plan

Define Your Domain: Choose your primary technical stack (e.g., Full-Stack, Backend, AI Engineering).
Commit to One Flagship System: Ditch small tutorial apps and focus on shipping a single high-impact product over 8–12 weeks.
Write High-Trust Technical Content: Document system architecture with real screenshots, video clips, and profiler metrics in technical blogs.
Execute the Distribution Ratio: Match your build effort with cross-platform distribution on X, LinkedIn, Reddit, and specialized tech hubs.
Maintain DSA Discipline: Solve pattern-based problem sets for 60 minutes daily to keep algorithmic fluency sharp.

Arka: An agent that thinks like an human

Sumit Mishra — Sun, 26 Jul 2026 16:56:39 +0000

See Inside Your Agents: Arka + SigNoz for Track 01

When a model returns 429, a shell step fails, or failover kicks in, you need to see which step broke — not just that something failed. We built Arka + SigNoz for the Agents of SigNoz hackathon (Track 01 — AI & Agent Observability) to instrument the full agent lifecycle with OpenTelemetry and make every step visible in one trace waterfall.

Demo video (~3 min): arka-signoz-hackathon-demo.mp4

Images: PNGs live on the signoz-hackathon-media release. If your editor (e.g. AWS Builder Center) does not render markdown images, paste the HTML blocks below or upload the PNGs from that release page.

What is Arka?

Arka is an open-source AI agent for your terminal. You say what you want in plain English; Arka routes the request to the right local skill, runs it on your machine, and falls back across 24 LLM providers when a model is actually needed.

Under the hood it is a Python CLI with a Fish-shell router, a multi-step goal loop, 70+ bundled skills, MCP for Cursor and Claude, and security gates on by default — prompt-injection checks, risky-action prompts, and hard blocks on destructive shell patterns.

Install in one line: uv tool install "arka-agent[chat,observability]" · Docs: arka-agent.mintlify.site

Why we love building it

We did not set out to build “another chat wrapper.” We wanted a real agent we could trust in our own terminals every day — one that routes fast, fails gracefully, and stays local when it should.

What keeps us shipping:

The router is the product. 120+ symbolic rules handle most requests with zero LLM tokens. Watching “summarize README” hit a skill in ~1 ms instead of a 3-second model round-trip never gets old.
Agents are messy — and that is the fun part. Routing, planning, tool calls, memory, failover, self-heal — every layer is a design problem. Arka is our sandbox to try ideas in production on our own repos.
Dogfooding forces honesty. When Gemini 429s mid-goal or a shell step fails, we feel it immediately. That pain is why we instrumented every span and wired SigNoz — we wanted the same visibility we wish every agent framework shipped with.
Local-first, extensible by design. Skills are plugins (skill.json), secrets stay in ~/.config/arka/, telemetry is opt-in. You own the stack; we just make the defaults sane.
Building in the open. Issues, routing mismatches, and hackathon demos like this one all land in the same repo. Shipping observability for Track 01 is part of making Arka something we are proud to hand to other developers.

If that resonates, star the repo — it helps others find it: github.com/Sumit884-byte/arka

The problem

AI agents are a black box. They chain LLM calls, invoke tools, hit vector DBs, and make decisions autonomously. When latency spikes, token costs explode, or an agent hallucinates in production, fragmented logs do not tell the end-to-end story.

Track 01 asks you to trace, monitor, and debug AI-native systems. That means one place to follow a request from routing → planning → LLM attempt → tool execution → recovery — with metrics and logs tied to the same trace IDs.

How we use SigNoz

We do not run a separate observability sidecar. Arka instruments itself with OpenTelemetry and sends traces, metrics, and logs to SigNoz over OTLP HTTP. SigNoz is where we deploy the stack, ingest telemetry, and debug the agent lifecycle.

1. Deploy with Foundry

SigNoz runs locally from casting.yaml + casting.yaml.lock at repo root. One command brings up the UI (:8080), OTLP ingester (:4318), and MCP server (:8000):

arka signoz setup -y

2. Enable telemetry in Arka

Add to ~/.config/arka/.env:

OTEL_TRACES_ENABLED=1
OTEL_METRICS_ENABLED=1
OTEL_LOGS_ENABLED=1
SIGNOZ_ENDPOINT=http://localhost:4318

Instrumentation lives in src/arka/telemetry/ — every agent step becomes exportable telemetry with no hand-rolled exporters.

3. Emit traces (synthetic or live)

arka signoz demo-scenarios --synthetic   # no live LLM required
arka goal -y -n 4 "count lines in README.md"   # live agent waterfall

Demo scenarios tag spans with arka.demo.scenario so you can filter in SigNoz instantly (vllm-vs-cloud-latency, rag-supermemory-cascade, semantic-router-split, e2e-observability-pillars, exception-stack-traces).

4. Debug in SigNoz UI

For the hackathon demo we use stock SigNoz views — no custom dashboard required:

View	Filter / use
Traces Explorer	`service.name = 'arka'` → full waterfall (`arka.route`, `arka.llm.attempt`, RAG spans)
Services	P99 latency, error rate, ops/sec for the `arka` service
Logs Explorer	LLM failover, 429 recovery, shell events on the same trace IDs as spans

Click any arka.llm.attempt span → Logs tab to see correlated agent events without switching tools.

5. Verify the stack

arka signoz status

Confirms Docker, foundryctl, OTLP pipelines, and built-in verify queries for routing spans, LLM attempts, and MCP tool calls.

6. Optional extras

Dashboards: arka signoz dashboard install — bundled panels in signoz/dashboards/
Alerts: arka signoz alert-create --all — error spike, LLM P99, token budget (needs SIGNOZ_API_KEY)
MCP: query traces from Cursor via SigNoz MCP on :8000 and the Cursor Agent Skills plugin

What we shipped

For this hackathon we instrumented Arka’s full agent lifecycle with OpenTelemetry and export everything to SigNoz over OTLP HTTP on port 4318.

Instrumentation lives in src/arka/telemetry/:

Signal	What Arka exports
Traces	`arka.request` → `arka.route` → `arka.agent.goal` → `arka.llm.attempt` → `arka.tool.shell`
Metrics	`arka.routing.decisions`, `arka.skill.duration`, `arka.llm.tokens`, `arka.mcp.ops`
Logs	Structured agent events with `trace_id` / `span_id` correlation

Every demo scenario tags spans with arka.demo.scenario so you can filter in SigNoz without guessing:

vllm-vs-cloud-latency — compare arka.llm.ttft_ms across providers
rag-supermemory-cascade — vector lookup → context → LLM complete
semantic-router-split — symbolic route (~1 ms) vs LLM fallback (~seconds)
e2e-observability-pillars — route → memory → LLM → shell in one waterfall
exception-stack-traces — auto-recorded exception.stacktrace on error spans

See How we use SigNoz for the full deploy → instrument → debug workflow.

Track 01 without a custom dashboard

Judges can verify the build with three SigNoz views:

Traces Explorer — filter service.name = 'arka'. You see real spans: arka.llm.attempt, arka.demo.inference_compare, arka.route.

Services — P99 latency, error rate, ops/sec for the arka service.

Logs Explorer — LLM failover events, quota errors, and provider 429 recovery correlated by trace ID. Filter service.name = 'arka' and open a trace to see log lines on the same IDs (e.g. route symbolic → goal loop, Gemini 429 failover to Groq, shell ok wc -l README.md, agent.self_heal retries).

Dashboards and alerts are bundled (signoz/dashboards/, arka signoz alert-create) for teams that want them — but the hackathon demo video and judge script focus on traces + services + logs.

Demo video: arka-signoz-hackathon-demo.mp4 (~3 min) · general Arka demo

Where to find docs (start here)

Resource	URL
Observability guide (setup, demo, dashboards, MCP)	arka-agent.mintlify.site/guides/observability
Hackathon judge pack (checklist, four pillars, demos)	signoz/README.md on fork
Blog / submission narrative (this page)	BLOG.md on release
Four pillars walkthrough	FOUR_PILLARS.md
MCP + Cursor skills	MCP_INTEGRATION.md · CURSOR_AGENT_SKILLS.md
Demo media (PNG/MP4)	signoz-hackathon-media release
Quickstart (install `arka-agent`, API keys)	arka-agent.mintlify.site/quickstart
SigNoz official docs	signoz.io/docs

Reproduce in 10 minutes

Prerequisites: Docker Desktop (≥4 GB RAM), Python 3.11+.

git clone https://github.com/Sumit884-byte/arka.git
cd arka
git checkout main
pip install -e ".[chat,observability]"

# Deploy SigNoz via Foundry (Docker + foundryctl + cast)
arka signoz setup -y

Or install without cloning:

uv tool install "arka-agent[chat,observability]"
arka signoz setup -y

Add to ~/.config/arka/.env (or repo .env):

OTEL_TRACES_ENABLED=1
OTEL_METRICS_ENABLED=1
OTEL_LOGS_ENABLED=1
SIGNOZ_ENDPOINT=http://localhost:4318

Emit synthetic agent traces (no live LLM required):

arka signoz demo-scenarios --synthetic
arka signoz status   # verify pipelines + judge filter queries

Open http://localhost:8080 → Traces Explorer → filter service.name = 'arka'.

For a live agent waterfall:

arka goal -y -n 4 "count lines in README.md"

Refresh SigNoz UI screenshots and rebuild the demo video:

python3 recordings/signoz-screenshots/capture_signoz_ui.py --no-dashboard
python3 recordings/build_signoz_demo_video.py

Four observability pillars

We mapped Arka directly to SigNoz's LLM observability story (FOUR_PILLARS.md):

1. End-to-end request tracing

Root span arka.request through routing, goal steps, LLM attempts, and tools. Filter: arka.demo.scenario = 'e2e-observability-pillars'.

2. Correlate traces with logs

emit_log() attaches the active span's trace ID. Click an arka.llm.attempt span → Logs tab shows llm tokens gemini/... on the same trace.

3. Token usage and cost analytics

Span attributes: gen_ai.usage.input_tokens, gen_ai.usage.output_tokens, arka.llm.estimated_cost_usd. Metric: arka.llm.tokens by provider and model.

4. Alerts

Bundled recipes: agent error spike, LLM P99 latency, token budget. Create with arka signoz alert-create --all (requires SIGNOZ_API_KEY).

Tech stack

Layer	Technology
Agent	Arka — CLI, Fish router, goal loop, skills
LLM	Agno — model-agnostic routing and chat
Telemetry	OpenTelemetry — OTLP HTTP → SigNoz `:4318`
Observability	SigNoz — traces, metrics, logs, Query Builder
Deploy	SigNoz Foundry — `foundryctl cast -f casting.yaml`
MCP (optional)	SigNoz MCP on `:8000` — Cursor Agent Skills plugin

Foundry and MCP

casting.yaml enables SigNoz MCP (mcp.spec.enabled: true) so you can query traces and metrics from Cursor via the SigNoz Agent Skills plugin. Judges can re-run:

foundryctl cast -f casting.yaml

and verify OTel traces land in SigNoz within minutes.

AI disclosure

Per hackathon rules, we declare AI assistant use:

Cursor — OpenTelemetry instrumentation, SigNoz wiring, docs, demo video script, screenshot capture automation, and this blog draft
LLM providers — used during normal Arka development and demo scenario design

Failure to disclose AI assistance disqualifies submissions; we list it here and in our Devpost form.

Links

Docs (observability): arka-agent.mintlify.site/guides/observability
Upstream repo: github.com/Sumit884-byte/arka
Hackathon fork: github.com/sumitmishra884byte-cpu/arka
Judge pack: signoz/README.md · FOUR_PILLARS.md · release media + docs
Hackathon: wemakedevs.org/hackathons/signoz
SigNoz docs: signoz.io/docs
Demo video: arka-signoz-hackathon-demo.mp4 (~3 min) · general Arka demo

YouTube / Devpost blurb: See inside your AI agents — not just that something failed, but which step broke. Arka instruments routing, LLM attempts, RAG retrieval, tool calls, and failover with OpenTelemetry; SigNoz shows the full waterfall in Traces Explorer, Services metrics, and correlated Logs Explorer. Reproduce: arka signoz setup -y → arka signoz demo-scenarios --synthetic → filter service.name = 'arka'.

Clone the repo, run arka signoz setup -y, then arka signoz demo-scenarios --synthetic. Open Traces Explorer, filter service.name = 'arka', and watch the full agent lifecycle in one waterfall.

My Headless LinkedIn Bot Fails Silently - Until I Point SigNoz at It

Sumit Mishra — Sat, 18 Jul 2026 08:05:52 +0000

Subtitle: From ChromeDriver 151 vs Brave 150 to correlated traces: what I learn instrumenting a Selenium cron job with OpenTelemetry

Every morning I open yesterday's log file and scroll, guessing.

Some days the bot sends zero connection requests. Other days it hits 27 of 30 and stops. The script runs headless on a schedule — no browser window, no Slack alert, just a text file that might not tell the whole story.

I built this for a SigNoz hackathon. The goal isn't a polished observability tutorial. It's to stop flying blind on a real Python + Selenium bot running on my Mac. Here's what actually breaks, what I instrument, and what shows up in SigNoz when I finally look.

What I Run

The bot sends LinkedIn connection requests up to a daily cap. I run headless Brave on macOS via launchd:

./schedule/install_daily_schedule.sh install
# At login + hourly while the Mac is on; at most one successful run per day

Relevant settings from .env:

BROWSER_HEADLESS=true
USE_BROWSER_PROFILE=true
USE_NETWORK_GROW=true          # fallback when people search is exhausted
AUTO_ACCEPT_INVITATIONS=true   # accept pending invites on Grow first
LINKEDIN_CONNECTIONS=30
LINKEDIN_DRIVER_AUTO_FIX_ATTEMPTS=2

SIGNOZ_ENABLED=true
OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
OTEL_SERVICE_NAME=linkedin-connection-bot

When people search runs out, the bot switches to My Network → Grow, accepts incoming invitations, then sends Connect requests. Resume state lets a crashed run pick up on Grow without redoing search. A wrapper script (schedule/daily_run.sh) handles lock files, stale process cleanup, and one chromedriver auto-fix retry.

Simple on paper. Messy in production.

The Failures I Can't See From One Log Line

ChromeDriver 151 vs Brave 150

On July 17, most hourly launchd checks looked like this:

Critical error: Failed to initialize brave: ...
This version of ChromeDriver only supports Chrome version 151
Current browser version is 150.0.7871.125

Brave hadn't auto-updated. Selenium had cached ChromeDriver 151. The bot never got past browser launch — zero connections, 784 lines of stack trace.

I add self-healing in Scripts/browser_utils.py: detect the mismatch, kill stale chromedriver and Brave processes, re-download the matching driver:

def auto_fix_chromedriver_mismatch(browser_name, log_func=None):
    cleanup_stale_bot_processes(browser_name, log_func=log_func)
    path = resolve_chromedriver_path(browser_name, force_refresh=True)
    _log(log_func, f"Auto-fix: resolved chromedriver at {path}")
    return path

That fixed launches once Brave caught up. But I still want to know when it happens without grepping logs at 7 a.m.

Almost Done: 27/30 and a Hangup

Late on July 17, after auto-fix worked, the bot resumed Grow-only mode and sent connections steadily — until:

Progress: 27/30 connections sent (grow)
Progress: 28/30 connections sent (grow)
Cleaning up bot browser processes...
./schedule/daily_run.sh: line 19: 52556 Hangup: 1               "$VENV_PYTHON" run_bot.py

Two short of the cap. Killed by SIGHUP. Without exported counters, the only signal is a progress line buried in a 700-line file.

Stale Locks

While one process is still running, the next hourly check logs: Another bot run is already in progress (pid 51947). Skipping. Earlier that evening I saw: Removing stale lock file. The lock logic is correct. Interrupted runs still leave footguns. Metrics like bot.driver_errors and bot.session_crashes surface this on a dashboard instead of me tailing files.

One Module, Three Signals

Everything lives in Scripts/telemetry.py — OTLP gRPC to port 4317, gated by SIGNOZ_ENABLED. Each run gets a 12-character bot.run_id on traces, metrics, and logs.

Spans: bot.run, bot.configure_browser, bot.login, bot.search_page, bot.accept_invitations, bot.connect_from_grow, bot.recover_session.

Metrics: bot.connections_sent (label source=search|grow), bot.invitations_accepted, bot.driver_errors (error_type=version_mismatch), bot.session_crashes, bot.run_success / bot.run_failure, bot.run_duration_seconds.

Main loop wiring:

tel.init_telemetry()
tel.log_event(logger, "Bot run started", phase="start")

with tel.span("bot.run", phase="run"):
    configurations()
    login(webpage, user)
    tel.record_run_outcome(success=not run_failed, connections_sent=connections_sent)
    tel.record_run_duration(time.time() - run_started_at)

On driver mismatch: tel.record_driver_error(error_type="version_mismatch") before auto-fix runs.

Logs append run_id and phase for trace correlation in SigNoz Logs Explorer:

Verify telemetry smoke test | run_id=87626c6dc93a phase=verify
trace_id=7b69827901b867b9f0658ed774ff684d  span_id=0e08651f63956788

One lesson I keep relearning: logs need explicit OTLP export. telemetry.py wires a LoggingHandler plus OTLPLogExporter — stdout files alone aren't enough.

Three-Pillar Correlation — The Part I Care About Most

SigNoz's real payoff for me isn't three separate tabs. It's jumping between logs, traces, and metrics without rebuilding queries. Unified observability means one run_id on every signal, and SigNoz UI links that carry filters and time range when I drill down (dashboard interactivity).

How my bot wires it

Pillar	What I emit	Correlation hook
Traces	Spans like `bot.run`, `bot.login`, `bot.connect_from_grow`	`bot.run_id` span attribute; root span wraps the whole cron run
Metrics	`bot.connections_sent`, `bot.run_success`, etc.	Same `bot.run_id` label on every counter/histogram sample
Logs	`log_event()` lines with `run_id=` and `phase=` in the body	`LoggingInstrumentor` injects `trace_id` / `span_id` when the log fires inside an active span (official guide)

Logs emitted inside a span carry both domain context (run_id=87626c6dc93a phase=verify) and OTel trace context (trace_id=… span_id=…). That second pair is what powers SigNoz's View trace button on a log line. Metrics don't get trace IDs on every sample — I correlate them through the shared bot.run_id label instead. SigNoz also derives APM/RED metrics from span data automatically (APM metrics from traces), which gives me operation-level rates alongside my custom bot.* counters.

Walkthrough: one smoke test, three pillars

After ./venv/bin/python Scripts/verify_telemetry.py prints run_id=87626c6dc93a:

Logs → trace. I open Logs Explorer, filter service.name = linkedin-connection-bot, and find Verify telemetry smoke test | run_id=87626c6dc93a phase=verify. The row shows trace_id and span_id. I click View trace (or the trace ID link). SigNoz opens the bot.verify_telemetry span — the same run I just emitted.
Trace → logs. On that trace's span detail panel I open the Logs tab (span details). SigNoz shows the correlated log line from step 1 without me re-filtering by hand. I can also click Go to related logs from the trace list view.
Trace → metrics. Back in Metrics Explorer I query bot.connections_sent with aggregation Sum, group by bot.run_id, and filter bot.run_id = 87626c6dc93a. I see source = verify with value 1 — the counter incremented inside the same span that produced the log. For a demo run with twelve simulated runs (signoz_demo_data.py), I group by source and spot the grow spike that matches a bot.connect_from_grow span in Traces Explorer.

That's the July 17 hangup story in reverse: instead of grepping 700 lines for Progress: 27/30, I click a log from the failed run, jump to bot.run, and check whether bot.connections_sent stopped climbing for that run_id.

Verify correlation in the SigNoz UI (5 minutes)

Run the smoke test, wait ~10 seconds for export, then check each pillar:

Step	Where	What to confirm
1	Logs Explorer → filter `service.name = linkedin-connection-bot`	Body contains `run_id=`; log attributes or body include `trace_id` and `span_id`
2	Click a log row → View trace	Trace opens with span `bot.verify_telemetry` and `bot.run_id` attribute
3	Trace detail → Logs tab	Same smoke-test log appears in the correlated panel
4	Metrics Explorer → `bot.connections_sent`, Sum, group by `bot.run_id`	Sample for your smoke-test `run_id` with `source = verify`
5	Traces Explorer → `service.name = linkedin-connection-bot`, span name `bot.verify_telemetry`	Span attributes include `bot.run_id` matching the log and metric label

If logs show run_id= but no trace_id, the log probably fired outside an active span — I make sure tel.log_event() calls sit inside with tel.span(...). If View trace is missing, I confirm LoggingInstrumentor ran (SDK OTLP export path per log collection methods) and that I'm on current telemetry.py with OTLP log export enabled.

Standing Up SigNoz and Verifying

docker compose -f pours/deployment/compose.yaml up -d
curl -s http://localhost:8080/api/v1/health   # {"status":"ok"}
nc -z localhost 4317 && echo "OTLP gRPC reachable"

./venv/bin/python Scripts/verify_telemetry.py
# run_id=87626c6dc93a

# Optional: realistic demo runs for dashboard screenshots (no LinkedIn traffic)
./venv/bin/python Scripts/signoz_demo_data.py --runs 12 --delay 2

A ClickHouse verification script confirmed logs, traces, and metric samples after smoke tests. For blog screenshots I also run signoz_demo_data.py, which emits a dozen simulated runs with varied run_ids, source=search|grow|verify on bot.connections_sent, histogram samples on bot.run_duration_seconds, and a mix of bot.run_success / bot.run_failure.

Tip: SigNoz Metrics Explorer defaults counters like bot.run_success to Rate over Last 30 minutes. Sparse cron jobs look empty even when data exists. Switch to Sum over Last 24 hours (or run demo data recently) to see cumulative run counts. Spans like bot.login and bot.connect_from_grow still need a full run_bot.py run — I skip that during verification to avoid live LinkedIn side effects.

Dashboards and Alerts (Designed, Not Yet Fired)

From my dashboard notes, the panels I build first: run health (bot.run_success vs bot.run_failure), throughput by source, driver errors plus session crashes, run duration p95, and recent bot.run traces.

Alert targets for my setup:

bot.run_success sum over 26h = 0 — no successful daily run (26h allows launchd drift)
bot.driver_errors where version_mismatch, sum over 1h > 0
bot.session_crashes sum over 15m > 0
No bot.* metric data for 26h — telemetry pipeline dead

I haven't fired these in production yet. They're the guardrails I wish I'd had before July 17.

What I Do Differently Now

Instrument before the first scheduled run. A verify_telemetry.py smoke test on day one beats log archaeology.

Partial runs need explicit failure signals. Stopping at 27/30 should increment bot.run_failure with connections_sent=27, not look like quiet success.

Put OTEL_* in .env, not just your shell. run_bot.py loads .env with override. My interactive shell had stale exports that confused early tests.

Headless Selenium observability is about phase spans and batch counters, not HTTP latency. But the pattern — one run_id on every signal — transfers to any cron-driven browser job.

The Bot Isn't Mysterious — It's Unobserved

ChromeDriver mismatches, stale locks, and a SIGHUP at 28/30 all leave evidence in flat files. Nothing aggregates it. OpenTelemetry plus SigNoz gives me one place to ask: did today's run succeed? How many connections? Which phase failed? Was it the driver again?

This works for my setup: local SigNoz via Docker, OTLP gRPC on 4317, macOS launchd, headless Brave. Your mileage will vary.

The full project — bot, telemetry module, SigNoz compose stack, verification scripts, and dashboard notes — is on GitHub:

https://github.com/Sumit884-byte/linkedin_connection_bot

If you're running a headless browser job on a schedule and only checking log files afterward, start with a smoke test and three signals. You'll thank yourself the first time ChromeDriver and Brave disagree.

Screenshots

ui-logs-linkedin-bot.png

ui-traces-bot-run.png

ui-metrics-connections-sent.png

ui-metrics-run-success.png

ui-services-overview.png

#	File	Use in section
1	`ui-logs-linkedin-bot.png`	Instrumentation / SigNoz verification — Logs Explorer with `run_id`, `phase`, trace correlation
2	`ui-traces-bot-run.png`	SigNoz verification — `bot.verify_telemetry` spans
3	`ui-metrics-connections-sent.png`	SigNoz verification — `bot.connections_sent` by source
4	`ui-metrics-run-success.png`	SigNoz verification — `bot.run_success` over 24h
5	`ui-services-overview.png`	SigNoz verification — Services page with `linkedin-connection-bot`