<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Logs on ilham.dev</title><link>https://ilham.dev/tags/logs/</link><description>Recent content in Logs on ilham.dev</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Sun, 27 Sep 2026 00:00:00 +0700</lastBuildDate><atom:link href="https://ilham.dev/tags/logs/index.xml" rel="self" type="application/rss+xml"/><item><title>How I convert time zones for logs and meetings without doing mental math</title><link>https://ilham.dev/posts/how-to-convert-time-zones-for-logs-and-meetings/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0700</pubDate><guid>https://ilham.dev/posts/how-to-convert-time-zones-for-logs-and-meetings/</guid><description>Time zone mistakes cause confusing incident timelines and missed meetings. I prefer converting explicitly instead of doing the offset in my head.
The Time Zone Converter tool is useful because it lets me check the result in a small, controlled place before I use it in a bigger workflow.</description></item><item><title>How I filter Docker logs without losing the useful lines</title><link>https://ilham.dev/posts/how-to-filter-docker-logs-without-losing-context/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0700</pubDate><guid>https://ilham.dev/posts/how-to-filter-docker-logs-without-losing-context/</guid><description>Docker logs can get noisy very quickly. A service may print hundreds or thousands of lines, and the line you need is often buried in the middle.
The basic command is:</description></item><item><title>How I parse logs before searching randomly</title><link>https://ilham.dev/posts/how-to-parse-logs-before-searching-randomly/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0700</pubDate><guid>https://ilham.dev/posts/how-to-parse-logs-before-searching-randomly/</guid><description>Logs become easier to investigate when they are split into fields instead of treated as one giant wall of text.
The Log Parser tool gives me a safe place to test the idea before I put it into a script, server, or production workflow.</description></item><item><title>How I read Unix timestamps without guessing seconds or milliseconds</title><link>https://ilham.dev/posts/how-to-read-unix-timestamps-without-guessing-seconds-or-milliseconds/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0700</pubDate><guid>https://ilham.dev/posts/how-to-read-unix-timestamps-without-guessing-seconds-or-milliseconds/</guid><description>A timestamp bug often starts with one question: is this value in seconds or milliseconds? Getting that wrong can move dates to 1970 or far into the future.
The Timestamp Converter tool is useful because it lets me check the result in a small, controlled place before I use it in a bigger workflow.</description></item></channel></rss>