Skip to content

Instantly share code, notes, and snippets.

View looneym's full-sized avatar
🐧
im in ur ifra breakin ur services

Micheál Looney looneym

🐧
im in ur ifra breakin ur services
View GitHub Profile
@looneym
looneym / dlq-automation-approaches.md
Created August 22, 2025 11:16
[claude-journal] DLQ Alarm Review Automation: Assisted vs CLI Tool Approaches

DLQ Alarm Review Automation: Two Approaches and Lessons Learned

The Problem Context

At Intercom, we have hundreds (nearly a thousand) of SQS dead letter queues (DLQs) with various paging priority levels. The challenge we were trying to solve was filtering and verifying which of these queues actually need to be paging our on-call engineers, particularly for lower priority issues.

As the dataset gets bigger, it becomes very difficult to maintain the right signal-to-noise ratio, but this has a real negative impact on those engineers when they're woken up in the middle of the night for something that just isn't really that important. The manual review process was becoming unsustainable - engineers would need to gather data from multiple sources (Terraform infrastructure, Honeycomb observability datasets, production metrics), analyze each queue's health and business impact, make decisions about appropriate paging tiers, and then implement approved changes across infrastructure.

This is exactly the kind of

@looneym
looneym / honeycomb-mcp-debugging-journal.md
Last active August 21, 2025 13:16
[claude-journal] Honeycomb MCP Remote Server Debugging - Classic Environment Limitations

Honeycomb MCP Remote Server Bug Report

Problem Summary

The remote Honeycomb MCP server at https://mcp.honeycomb.io/mcp was working correctly for several days but has suddenly stopped functioning. All data query operations now return "Invalid or missing environment" errors, despite the server successfully authenticating and returning workspace context. The workspace context claims "MCP tools do not function in Classic environments," but these same tools were working fine until recently.

Timeline

  • Working Period: MCP server functioned correctly for multiple days
  • Used Successfully: DLQ alarm investigations, production data queries, worker analysis
@looneym
looneym / sleep-driven-architecture-gist.md
Created August 20, 2025 16:18
The Sleep-Driven Architecture: Danny Fallon's Revolutionary Insight About Distributed Systems [claude-journal]
@looneym
looneym / claude-prompt-sharing-guidelines.md
Created June 26, 2025 17:48
[claude-prompt] Prompt Sharing Guidelines for Claude

Prompt Sharing

When El Presidente wants to share specific prompting approaches or guidelines with others, I should create shareable gists containing the prompt content.

Types of Prompts to Share

  • Configuration sections: Portions of this CLAUDE.md file that others might find useful (like the Session Journaling guidelines)
  • Ephemeral prompts: Prompting techniques or frameworks we develop during a session that could benefit other teams
  • Workflow instructions: Step-by-step processes we've refined for specific tasks
  • Best practices: Guidelines we've discovered for working with Claude effectively
@looneym
looneym / session-journaling-prompt.md
Created June 26, 2025 17:45
[claude-prompt] Session Journaling Guidelines for Claude

Session Journaling

When El Presidente asks me to "journal" about a working session, I should create a written summary that captures the engineering discussion and can be shared with the team.

Journaling Style and Structure

  • Tone: Casual but professional - write as an engineer summarizing a working session with El Presidente
  • Perspective: Third person, factual account of what we tried and learned
  • Length: Keep it concise - aim for 3-4 paragraphs total
  • No structured headings: Use flowing narrative paragraphs, not bullet points or formal sections
@looneym
looneym / feature-flag-design-session.md
Last active June 26, 2025 17:43
[claude-journal] Feature Flag System Design Session - Read-Through Cache with Background Population

El Presidente and I had a working session to design a feature flag system for nexus-go to support gradual infrastructure rollouts, specifically migrating from Redis to Valkey. The challenge is that this application handles about 20M events in 10-second windows across 150 production hosts, so performance is absolutely critical.

Initially we took the obvious approach - on-demand DynamoDB lookups with local caching. Each feature flag check would hit the local cache first, then fall back to DynamoDB on a cache miss. This seemed reasonable until we did the math on the scale. At 2M events per second, even with 1-minute caching, cache misses for new features could generate millions of simultaneous DynamoDB calls. We briefly considered switching from app_id-based flags to app_stage-based flags (using the MUSTER_PROFILE env var) to reduce the lookup space, but we realized we'd still have the same rate limiting issues - every single event would still need to check the feature flag, just with a different key. We actual

module IntercomUtil
require 'intercom'
TOKEN = ENV["INTERCOM_PAT"]
@intercom = Intercom::Client.new(token: TOKEN)
def self.get_all_conversations
open_convos = @intercom.conversations.find_all(open: true)
closed_convos = @intercom.conversations.find_all(open: false)
@looneym
looneym / docker-compose.yml
Created July 9, 2017 02:48 — forked from EloB/docker-compose.yml
Docker compose yml hello world example
helloworld:
image: ubuntu:14.04
command: /bin/echo 'Hello world'
<details>
<summary>Summary Goes Here</summary>
```
lol
```
</details>