Observability
npx -y skills add athal7/dotfiles --skill observabilityAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Investigate production issues using logs, traces, and errors — how to triage, correlate signals, and know when to escalate.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
2.8 KB, as published. Nobody here has run it
Use this skill to investigate production problems. For query syntax, index patterns, and example queries, consult the log query reference.
Triage process
Start with the symptom, not the tool. Before querying anything:
- State the hypothesis — what do you think is wrong and why?
- Bound the time window — when did it start? Is it ongoing or resolved?
- Identify the scope — one service, one endpoint, one user, or system-wide?
This prevents aimless log-scrolling and makes findings interpretable.
Signal hierarchy
Work top-down — coarser signals first, drill into finer ones only when needed:
| Signal | What it tells you | When to use |
|---|---|---|
| Error rate / rate spike | Something broke at scale | First check — confirms the problem is real |
| APM traces | Which transaction is slow or failing, full call chain | Once you know the scope |
| APM errors | Exception type, stack trace, grouping key | When you need the root cause code path |
| Logs | Raw context around a specific event | When traces don't have enough detail |
Don't start with logs. Start with traces or error groups, then use trace.id to pull the surrounding log context.
Correlating signals
The trace.id field links all three indices (logs-*, traces-apm*, logs-apm.error-*). Once you have a trace.id from an error or slow trace, use it to pull all logs from that same request:
{"term": {"trace.id": "<trace-id-here>"}}
Asking the right questions
Before querying, write down what a "confirmed" answer looks like. Examples:
- "If query returns 0 errors for service X in the last 1h, the issue has resolved"
- "If the slow trace shows N+1 queries on endpoint Y, the cause is clear"
- "If errors spike at exactly :15 and :45 of every hour, it's likely a cron job"
This prevents misreading absence of evidence as evidence of absence.
When to escalate
Stop investigating and escalate to the team when:
- Error rate is sustained above baseline for > 15 minutes and cause is not identified
- A trace shows calls to an external dependency timing out (not your code)
- Errors reference a data migration or schema change (potential data integrity issue)
- You've ruled out the obvious causes and need production access or context you don't have
Common patterns
| Symptom | Where to look first |
|---|---|
| Slow page loads | APM traces — sort by transaction.duration.us desc |
| 500 errors spiking | APM errors — group by error.grouping_key |
| One user affected | Logs — filter by user ID or session ID |
| Periodic issue | Logs — look for time pattern in @timestamp |
| After a deploy | APM errors — filter by @timestamp after deploy time |
Gives 0 of the 12 instructions most monitoring observability skills give
Counted across 481 of the 483 authors here whose files we hold, read 2026-08-06
- link every alert to a runbookin 43 of 481, across 35 files
- use structured json loggingin 36 of 481, across 31 files
- alert on user-facing symptomsin 20 of 481, across 15 files
- emit structured JSON logs with stable event namesin 18 of 481, across 13 files
- propagate trace context across boundariesin 16 of 481
- use histograms for latency trackingin 14 of 481, across 9 files
- use OpenTelemetry for distributed tracingin 13 of 481, across 8 files
- include a correlation ID on every log linein 13 of 481, across 8 files
- Define service level objectivesin 10 of 481, across 7 files
- Call useAzureMonitor before importing other modulesin 9 of 481, across 2 files
- stop and ask for clarification if inputs are missingin 9 of 481, across 2 files
- define on-call questions before adding telemetryin 9 of 481, across 4 files
Said here and by no other author read
- state the hypothesis before querying
- bound the time window before querying
- identify the scope before querying
- check error rate or rate spikes first
- drill into APM traces once scope is known
- use APM errors for root cause code paths
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.