Operational work — triage, diagnosis, ticket follow-through — used to need a team because the cost of each task wasn’t the work itself. It was the context switch. Open a tab. Click into the org. Tweak the filter. Read a row. Click. Switch product. Different vendor, different syntax. Every dedicated tool added another tab and another mental model. An AI coding agent in the terminal collapses the switching. The next step is the robots receiving the alarm, filing the GitHub issue, triaging, proposing the fix. The person stays in flow.
The cost is the context switch — and the clicking
Pick any production incident from the last year. Someone messages you that something’s broken. You open a dashboard. Click into the org. Click into the time range. Tweak the filter. Read a row. Click into the row. Read the stack. Right-click. New tab. Switch to a different vendor. Click back through their nav. Different filter, different syntax. Click back.
The line items that cost the most weren’t the queries. They were the dashboard tabs, the clicks, the half-seconds of cognitive load each time I had to re-orient to a different vendor’s mental model. Vendor UIs were invented to make that overhead tolerable for humans — which is why every observability product on the market has a beautiful dashboard. Their core value proposition is “we make tab #N less painful.”
Once you don’t need the tab, the value proposition collapses.
Vendor UIs were invented to make tab-switching tolerable for humans. Once you don’t need the tab, the value proposition collapses.
Every dedicated tool is a separate surface to manage
The trap that catches small teams: assume specialised tools are operationally free because they’re just a SaaS subscription. They’re not. Every dedicated tool brings a console to log into, a permissions model to keep current, an API key to rotate, a billing cycle to renew, an integration to break the next time the vendor sunsets a plan tier, and a UI muscle memory to rebuild after six weeks of not using it.
Sentry for errors. Datadog or New Relic for APM. Logtail, Splunk or Grafana Loki for logs. LogRocket or FullStory for session replay. PagerDuty or OpsGenie for on-call. Better Stack or Pingdom for uptime. Statuspage or Instatus for the public status page. Mixpanel or Amplitude for product analytics. LaunchDarkly or Statsig for feature flags. Linear or Jira for tickets. Intercom or Zendesk for support inbound. That’s eleven categories before anyone has shipped a single feature, and a small team will easily have six or seven of them on the bill.
Each one was the obvious choice for its category. Each one made tab #N less painful. None of them was free.
The new day-to-day
A ticket lands. “Customer says they got a blank page at 14:32, can you check?”
The old workflow: open the error monitoring dashboard, scope to the user ID, scope to the time window, find the stack trace; switch to the deploy dashboard to check what shipped; switch to the LB metrics to see if there was a 5xx spike; switch back to error monitoring to confirm. Six tabs, twenty minutes, three context switches, attention shredded.
The new workflow: open the terminal where I was already working. “Did any client error fire around 14:32 for user X?” Claude writes a CloudWatch Logs Insights query, runs it via the AWS CLI, pastes the result. “Did the ALB throw 5xx around the same time?” It writes the second query. “What was the last deploy?” It checks the ECS task definition. Three sentences, one terminal, no clicking, no syntax to remember.
I spent my attention on deciding what the answer means, not on extracting it.
I spent my attention on deciding what the answer means, not on extracting it.
Where this is heading: the robots run the inbox
Today the agent is reactive — I ask, it answers. The next step makes it proactive.
When the production alarm fires, the webhook posts the structured payload as a GitHub Issue automatically. An agent reads the issue, queries the logs around the timestamp, checks whether the fingerprint matches an existing open issue, then posts triage notes as a comment: “new fingerprint, four users affected, stack points at interview-prep.tsx:142, likely a null on the style lookup.”
For a familiar pattern, the agent opens a PR with the proposed fix and links it to the issue. For an unfamiliar one, it gathers the surrounding diagnostics — related log lines, recent deploys, similar past incidents — and posts a synthesis comment for me to review.
By the time I open the GitHub tab in the morning, half the inbox is already triaged, several issues are linked to draft PRs, and the unfamiliar ones have enough context attached that the decision is the only work left. The human stays in approval mode; the robots do the legwork.
That isn’t theoretical. The pieces all exist: alarm webhooks, GitHub’s API, an agent that can read structured payloads and run queries. What’s left is the wiring, and the wiring is exactly the kind of one-afternoon prompt-driven setup the rest of this site documents.
What an ops team of one feels like
A normal day: I do feature work. Tickets arrive in batches via GitHub, half of them already triaged. The unfamiliar ones get five to ten minutes of my attention, including the human judgement — compared to the twenty minutes of tab-switching the old vendor stack would have demanded just to extract the same facts.
Two SaaS products, 360 users, one operator, no on-call rotation. Not because nothing breaks — things break — but because the cost of dealing with breakage no longer dominates the cost of building. Vendor consoles were the thing that fragmented attention. Once an agent reads them for me, my attention stays in one place. The terminal is the console; the GitHub inbox is the ticket queue; the robots are the support and DevOps team.
Two SaaS products run on $125 a month of infrastructure by one operator. Coffee-Budget Software details the stack; Prompts That Ship Part 10 documents the four-source error-monitoring setup behind those CloudWatch queries.