Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add rules/girijashankarj/cursor-handbook/monitoringgit clone --depth 1 https://github.com/girijashankarj/cursor-handbookWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/rules/girijashankarj/cursor-handbook/monitoring)<a href="https://agentmods.dev/rules/girijashankarj/cursor-handbook/monitoring"><img src="https://agentmods.dev/badge/rules/girijashankarj/cursor-handbook/monitoring.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00565 | $0.00565 |
| Opus 5 | $0.00282 | $0.00282 |
| Sonnet 5 | $0.00113 | $0.00113 |
| Haiku 4.5 | $0.00056 | $0.00056 |
Grade A, and why
monitoring scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured today.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
What it actually says
Monitoring & Observability Rules
Three Pillars of Observability
1. Logging
- Structured JSON format for all logs
- Every log entry MUST include:
timestamp,level,correlationId,service - Log levels: ERROR → WARN → INFO → DEBUG
- NEVER log PII, secrets, or full request/response bodies
- Use sampling for high-volume debug logs in production
{
"timestamp": "2026-01-15T10:30:00Z",
"level": "info",
"correlationId": "abc-123-def",
"service": "{{CONFIG.project.name}}",
"operation": "createOrder",
"duration_ms": 245,
"status": "success"
}
2. Metrics
Key metrics to track:
- Request rate (requests/second)
- Error rate (errors/total requests)
- Latency (p50, p95, p99)
- Saturation (CPU, memory, disk, connections)
- Business metrics (orders/minute, signups/day)
3. Tracing
- Implement distributed tracing across all services
- Propagate trace context via headers (
traceparent,tracestate) - Record spans for: HTTP calls, DB queries, cache operations, queue operations
- Sample traces at 10% in production, 100% in staging
Alerting Rules
Severity Levels
| Severity | Response Time | Example |
|---|---|---|
| P1 - Critical | 15 min | Service down, data loss |
| P2 - High | 1 hour | Degraded performance, partial outage |
| P3 - Medium | 4 hours | Elevated error rate, slow queries |
| P4 - Low | Next business day | Warning thresholds, capacity planning |
Alert Thresholds
- Error rate > 1% for 5 minutes → P2
- Error rate > 5% for 2 minutes → P1
- p99 latency > 2s for 10 minutes → P3
- CPU > 80% for 15 minutes → P3
- Disk > 90% → P2
- Service health check failure → P1
Dashboard Requirements
Every service MUST have a dashboard with:
- Request rate and error rate over time
- Latency percentiles (p50, p95, p99)
- Resource utilization (CPU, memory)
- Active connections / concurrent requests
- Business-specific metrics
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- today First seen · 68 lines · 565 tokens per session scan A bc268713c20a
monitoring is a cursor rule published in the GitHub repository girijashankarj/cursor-handbook (30 stars, last pushed 4d ago), licensed MIT. It adds 565 tokens to every session, about $0.0028 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other cursor rules, from other repositories
graphstack
GraphStack v4.7.1 — Orchestrated, graph-first, GNAP-tracked AI development (cross-platform).
code-optimization
Guidelines for optimizing duplicate and poorly structured code.
mcp
Guidelines for implementing and interacting with the Task Master MCP Server.
new_features
Guidelines for integrating new features into the Task Master CLI.
commands
Guidelines for implementing CLI commands using Commander.js.
git_workflow
Git workflow integrated with Task Master for feature development and collaboration.