Mailcow logs viewer: A faster, cool way to monitor your emails

shlomi · 2025-12-25T18:47:39+00:00

Hi everyone, While mailcow is an amazing suite, I often found the built-in log viewing options a bit clunky when I needed to debug something quickly (its ev...

shlomi

timber
just shlomip/mailcow-logs-app:dev not ghcr

timber

shlomi right on. that worked!

shlomi

timber
this is a dev image so there may be bugs

ayozeve

Hi there,

First of all, I wanted to say thank you for this amazing tool. The Mailcow Log Viewer is absolutely brilliant and it has become an essential part of my workflow.

I have a small suggestion that might improve the accuracy of the data. Currently, I noticed that the timestamp displayed for each message seems to be the time when the log is processed or “dumped” into the app. Would it be possible to extract and display the original timestamp from the log entry itself instead?

When troubleshooting specific delivery issues, having the exact original second the event occurred in Postfix would be incredibly helpful for cross-referencing.

Thank you again for your hard work on this project!

Best regards,

DocFraggle

ayozeve This never occured to me, but you are right! For now you can click the message and have a look at the “Logs” tab, there you have the Postfix timestamps. But I agree, it would be better to have the Postfix timestamp on the overview page as well

shlomi

ayozeve

Thank you 😀

Regarding your suggestion about timestamps: it’s a great point. Currently, when the system is running continuously, the “processed” time is usually very close to the event time. However, I see how the discrepancy matters for deep troubleshooting.

The challenge with Postfix logs is that a single message can generate multiple log entries over time (e.g., if it’s queued or retried), each with a different timestamp. On the other hand, Rspamd records a single, consistent value for each email.

Would using the Rspamd timestamp as the primary reference work for your needs? It seems to be the most reliable “source of truth” for a single event.

ayozeve

Hi Sshlomi and DocFraggle,

Thank you both for the quick and positive feedback!

Regarding your question: Yes, using the Rspamd timestamp as the primary reference could be an excellent idea.

As you mentioned, having a single, consistent “source of truth” for each email is exactly what is needed. It would solve the discrepancy during deep troubleshooting and provide a much cleaner overview than the current “processed” time.

I truly believe this change would be a great improvement for everyone using the app, as it aligns the visual data with the actual flow of the mail server. It makes the tool much more precise for any administrator.

Once again, I am very grateful for your hard work and dedication to this project. The tool is outstanding.

Thanks again for considering this!

Best regards,

pittbull

WOW! This is by far one the better products I’ve come over in quite some time.

Install on first try, excellent documentation and a beautiful dashboard showing me exactly what I’ve been craving to see.

Kudos @shlomi - excellente work.

disgustipated

Considered opening a github issue but dont feel i have enough details just yet. since the last update there seems to have been a significant uptick in calls to the logs, multiple times a second. these are /api/v1/get/logs/ calls to each of the services like sogo, rspamd, watchdog. not sure if this is expected. the raw logs fetch is set to the default of 20

shlomi

disgustipated
In the next version (I’ll probably release it later today) I’ve completely changed how logs are been pulled from mailcow.
I’d appreciate it if you could check again after the update and update me if there are any problems.

kadybee

This is frikkin’ awesome! 10 minute install and works out of the box.

If not integrated into Mailcow, it would nice to have a single instance connect to different mailcows - ie select mailcow server2 etc.

Thanks for this brilliant tool.

shlomi

kadybee
Implementing this would require significant changes and troubleshooting, as i will need to map every log and setting in the db to its specific system. I’d rather focus my time on core app improvements. It’s far more efficient to simply spine up a separate instance. as you can see, is a very straightforward process.

kadybee

shlomi Yes, totally agree. Even as a docker newbie+, it didn’t take long to adjust and fire up a couple of simultaneous instances as Projects on the one machine.
The more I pour through the output provided, the more impressed I am with your idea and work.
Outstanding! Thank you.

storpotaten

After update:
root@mail1:/opt/mailcow-logs-viewer# docker compose logs -f app
mailcow-logs-app | INFO: Started server process [1]
mailcow-logs-app | INFO: Waiting for application startup.

It never starts, any idea?

Regards // Mike

Gebemsea

storpotaten
Sounds similar to ShlomiPorush/mailcow-logs-viewer56
To test: stop the stack, remove ./data/*mmdb (these should be redownloaded automatically), try to start again, e.g.:

docker compose down
rm ./data/*mmdb
docker compose up -d

This might get you running again, but if the info in the above report is correct, it won’t solve ths issue permanently,

storpotaten

Solved it now anyway.
Thank you very much.

Angus_MacGyver

Dear all,
I’m more of a “User-Nerd”; so allow me a question:
How does one setup for Mailcow Logs Viewer to be reachable through a domain (e.g. logs.mailcow.server) and also using HTTPS/Lets Encrypt? > Any How-To would be appreciated!

Mailcow Logs Viwer is installed just alongside mailcow on the same server.

Best regards,
MacGyver

esackbauer

Angus_MacGyver
Easiest way is per reverse proxy.

Angus_MacGyver

esackbauer
Seems like much overhead for me to additionally install NPM (Nginx Proxy Manager) or some other “full” reverse proxy.
Would it be possible to set something “more easy” up with https://docs.mailcow.email/manual-guides/Nginx/u_e-nginx_custom/ and https://docs.mailcow.email/post_installation/firststeps-ssl/?

Kevo

See the post(s) from timber above from 18 Mar and following.

I took that proxy config and a couple of changes to the docker config timber posted to set up my system. It uses the existing nginx like you found on the custom sites docs to proxy to the mail logs viewer app.

You will also need to add the site name for the mailcow logs app into the additional SAN setting in mailcow.conf for it to pull a cert from let’s encrypt.

« Previous Page Next Page »