All posts
Guides
Alerts that fire on what customers feel
Why we alert on failed checkouts and slow logins instead of CPU, and how to write your first rule.
Priya Natarajan
·
7 min
Why we alert on failed checkouts and slow logins instead of CPU, and how to write your first rule.
The short version
Most teams collect far more data than they read. The trick is deciding in advance which signals always matter, then letting everything else be sampled, summarised or dropped.
How to try it
Open any project, go to Settings, and turn on the default rules. You can see exactly what was kept and why in the Sampling panel.
What to watch for
If a rule drops something you needed, add an exception from the log line itself. It takes effect within a minute.
Priya Natarajan
Writes about logging, tracing and on-call at Tessellary.
KEEP READING
More from the blog.
Guides and notes from the team.
Engineering
How we sample logs without losing the ones that matter
Keep every error and every slow request, drop the noise. Here is the rule set we ship by default.
Guides
Tracing a request from the browser to the database
A plain walkthrough of distributed tracing, with one real checkout request as the example.
Guides
Alerts that fire on what customers feel
Why we alert on failed checkouts and slow logins instead of CPU, and how to write your first rule.