<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Monitoring on Daffa Abhipraya</title><link>https://blog.abhipraya.dev/tags/monitoring/</link><description>Recent content in Monitoring on Daffa Abhipraya</description><generator>Hugo</generator><language>en-us</language><copyright>© Daffa Abhipraya</copyright><lastBuildDate>Sat, 11 Apr 2026 00:00:00 +0700</lastBuildDate><atom:link href="https://blog.abhipraya.dev/tags/monitoring/index.xml" rel="self" type="application/rss+xml"/><item><title>PPL: Self-Hosted Error Monitoring with Custom Instrumentation</title><link>https://blog.abhipraya.dev/ppl/part-a/monitoring/</link><pubDate>Sat, 11 Apr 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-a/monitoring/</guid><description>&lt;p>Error monitoring is one of those things that feels optional until the first production bug slips through unnoticed. A user reports &amp;ldquo;the page is broken,&amp;rdquo; you check the server, everything looks fine, and three hours later you discover a background task has been silently failing since the last deploy. This blog covers how we built monitoring that catches those failures before users do.&lt;/p>
&lt;blockquote>
&lt;p>&lt;strong>Note:&lt;/strong> Our project is hosted on an internal GitLab instance, so we use the term &lt;strong>MR (Merge Request)&lt;/strong> throughout this blog. If you&amp;rsquo;re coming from GitHub, MRs are the equivalent of &lt;strong>Pull Requests (PRs)&lt;/strong>.&lt;/p></description></item></channel></rss>