A while back, I found myself sitting on public transit, digging through Cloudwatch logs on my phone so that I could debug an app right before a live launch party. It was a terrible experience for someone who isn't super used to quickly parsing the mess of timestamps and INVOCATION STARTs. I was frustrated by the experience, and I thought to myself, "There has to be a better way to do this." So I built FriendlyLog, a simple web app that lets you view your AWS CloudWatch logs in a more user-friendly way.
The good
- It works! I can now view my logs in a much more readable format, and I can filter them by function name, log level, date range, and other criteria.
- I grouped the logs by invocation and kept the original logs tucked away in a collapsible section, so you can still see the raw logs if you need to
- I've used icons and colors so you can easily see errors, timeouts, coldstarts, etc
- It sends a daily email summary (easily opt in and out) with the error rates and an optional AI-generated summary. (Because everyone has to build an AI wrapper)
- I don't record actual user logs for security purposes; instead, I store some stats about the logs, like the number of errors, cold starts, and timeouts, so I can provide a summary without storing sensitive information.
- The whole process was really good practice with Supabase auth, Next SSR, and AWS APIs
- I'm generally really proud of the design, from the logo to the dashboard log displays
The bad
- It's only very specifically for AWS Lambda logs, so it's not a general-purpose logging solution. Filtering and grouping is so service-specific that I would need to add them individually, which I did not expect.
- Configuring a large number of log groups with enough flexibility for the user to determine usefulness is a bit of a pain
- Needing to have users set up an IAM policy to have Friendlylog use STS to temporarily assume user permissions feels really weird. It works great, but needing users to copy/paste stuff into their root accounts is a bit of a barrier to entry.
- I'm not sure how useful the email summaries actually are unless there's a huge volume of logs, which I can't really test
- I would probably need to store more metadata about the logs for longer to make the summaries more useful
- I am not that confident that I want to even be storing metadata about user logs in my free-tier Supabase project at all
The future
I am considering rewinding/de-opinionating the user profiles, authentication and onboarding flow and adding database schema and instructions to make this tool available as a self-hosted instance. That way, devs can add their own LLM API and support for the log types they need, based on my existing code. Plus the could use their own credentials to access the AWS SDK instead of doing the whole IAM user setup and letting me access their AWS accounts
Other than that, I think it's safe to call this SaSS dead. It's been a lot of fun to build, but I think I may be the only person at the exact intersection of "wants pretty logs" and "is willing to deal with the setup necessary to make that happen"
FriendlyLog features:
- Supabase authentication and user management
- Sensible grouping of logs by service and invocation, with the original logs tucked away in a collapsible section
- Filtering by function name, log level, date range, and other criteria
- Icons and colors to easily identify errors, timeouts, cold starts, etc.
- Daily email summaries with error rates and optional AI-generated summaries
And was built with:
- nextjs
- supabase
- daisyUI (tailwind)
- AWS SDK for interacting with AWS services
- AWS STS (Security Token Service) for temporary credential management

