Console.text()
SMS alerts for your code just like console.log()
68 followers
SMS alerts for your code just like console.log()
68 followers
Stop anxiously checking dashboards. console.text() sends you an SMS when specific code paths execute. One line of code. No complex setup. Perfect for solo devs who want simple production alerts without the overhead of Sentry or PagerDuty.
Free
Launch Team
Render Sandboxes: a computer for every agentIsolated compute, persistent state and a real filesystem
Promoted
Hey everybody I'm Noel, and I just shipped my first product - console.text()!
Two weeks ago, I deployed a payment processing update at 11 PM. Went to bed. Woke up to Slack messages, it had been failing silently for 6 hours. Cost us real money (Not that much💀).
I thought: "Why isn't there a stupidly simple way to just... text me when critical code runs?"
Sure, Sentry and PagerDuty exist. But setting them up for a side project feels like using a sledgehammer to hang a picture frame.
A while back I also watched a video by Jason Goodison about building micro-SaaS products. He mentioned this exact idea.
Honestly, I have no idea if this is useful. Maybe developers already have monitoring solved. Maybe SMS alerts are annoying. Maybe this is a solution looking for a problem.
please go ahead and signup and help me test: console-text
How it works:
first sign up and get your live api key
then:
install package: npm install @holler2660/console-text
What you get:
- 50 free messages to test it out
- 10 unique messages per 5-min window
What I need:
1. Is this solving a real problem for you?
2. What features would make you actually use this?
3. What would you pay? (I'm thinking $5-15/mo but genuinely have no clue)
4. Be brutally honest
Thanks for checking this out! I'll be here all day answering questions, taking feedback, and probably nervously refreshing this page every 30 seconds 😅
This is excellent. But can this feature be integrated into emails, Slack, or Telegram?
We tend to overlook SMS, as they tend to get lost in the sea of promotional messages.
@chilarai Absolutely! Email, Slack, and Telegram are on the roadmap, multiple people have asked for this.
You're right about SMS getting lost in promo spam. I'm thinking:
Multi-channel approach:
console.text('Critical: Payment failed', {
channels: ['sms', 'slack', 'email']
});
Or even simpler methods:
console.email('Info: Backup complete');
console.slack('Deploy finished');
console.text('URGENT: Server down');
@noel44 looking forward
I think the core is a good idea but why SMS, it could also be just via SMTP mail and litereally cost nothing? SMS can become quite expensive if you have a bigger side project where a lot of messages are sent then. I would stick to email and send it to an email address that has priority on your phone so it notifies you like a SMS would do. Maybe I'm wrong but that are my 2 cents
@jim_engine You're absolutely right - SMS costs add up fast (~$0.0075/msg in US, so 1000 msgs = $7.50)
Honestly, I should support BOTH and let users choose per alert:
console.text('Critical: Payment failed', { channel: 'sms' });
console.text('Info: Backup completed', { channel: 'email' });
or something like console.mail() (easier to remember).
I'm also planning WhatsApp, mail, even calling in priority cases, but that's up to the user.
Would you use it if I added email as a channel option? What would be your preferred default?
Also considering Slack/Discord webhooks for the same reason - different urgency levels need different channels.
Thank you so much for the feedback
@jim_engine @noel44 Wouldn't the logs fill up the mailbox with lot's of pointless logs especially for console.mail('Info: ');? And also what's the difference with just having to use sentry to monitor the errors even though the project is a small project sentry would still help and you don't have to pay for it unless you are getting lots of users. I feel this would be good if the errors cross a certain threshold, or else your sms would be filled with lots of error logs same with the mailbox if you eventually implement it.
@jim_engine @uchenna_nwaorgu Valid concern, but that's exactly why I built rate limiting.
How it works:
- 10 unique messages per 5-min window max
- You control what gets sent - it's not automatic log collection
Sentry monitors EVERYTHING and you filter down.
This is the opposite - you explicitly tag what matters:
// Not this:
console.log('user clicked button'); // noise
// Only this:
console.text('Payment failed'); // you chose to send it
The difference:
- Sentry = "tell me about all errors, I'll check the dashboard later"
- This = "wake me up for THIS specific thing RIGHT NOW"
Different tools, different jobs. I use both - Sentry for debugging, this for "oh shit" moments.
Fair pushback though, if you're spamming yourself with console.text('Info: xyz') everywhere, you're using it wrong. It's for critical paths only.
Does that make sense or am I missing your point?
@noel44 If I were you I would add all possible options so the user can decide which fits him best. So give the user a choice from a pool of options but also not just 1 option, maybe even let them select multiple. For example I would like to get Email and Whatsapp (just in case). So give them this option at least with multiselect:
- Email
- Whatsapp
- Slack
- Telegram
- SMS
@jim_engine Multi-channel makes total sense.
So you're thinking something like:
And in the dashboard, users configure:
Critical → Email; WhatsApp ;SMS
Warning → Email ;Slack
Info → Email
Or even:
This is going straight into the roadmap. Would you beta test it when I build it?
Unrelated to the product itself, it would be nice if you change the screenshots/demos all to use `import from` (esm). I don't trust libraries that use commonjs `require` cuz those imply that your library is old/outdated and reduces trust. My first thought would be: "This is a new library.. Why are they using commonjs? Do they know enough about web development to write a trustworthy secure service/library? They also put the code on the console global, another general bad practice, hmm I definitely don't trust this library. Do they know what tree-shaking is, or are they just trying to ride the hype wave?"
Other than that, this cool idea, and I think the most I would enjoy with something like this is transparent pricing ("Free forever" and "50 free messages to get started" is contradicting I would close page and search for something else), a simple easy to understand dashboard with automatic usage limits with email warnings, an option to import the console.text without putting it on console global, focus on esm. Good thing is that the library has no dependencies, should stay that way. Use 2fa when publishing to npm. When you have the time, pimp up the landing page a bit to make it more trustworthy too. Make everything as clear as possible to the user to gain trust. Wish you great success on your journey...
@samuel_braun Thanks a lot for taking the time to write this, genuinely appreciate the depth and honesty here.
You’re absolutely right on multiple points:
ESM vs CommonJS:
The screenshots using require are a fair criticism. The SDK itself is intentionally dependency-free and minimal, but the docs and demos should absolutely default to ESM (import), and I’ll be updating them to reflect that. Supporting ESM-first usage (with CJS as a fallback) is the right call.
Global console patching:
This is meant to mirror the ergonomics of console.log() for quick adoption, but I agree it shouldn’t be the only option. Providing a clean, explicit import (e.g. import { text } from "console-text") without touching globals is something I’m planning.
Tree-shaking / modern tooling:
Totally valid concern. Keeping the library tiny, dependency-free, and tree-shakable is a priority, and I’ll make that more explicit both in implementation and documentation.
Pricing clarity:
You caught a real issue there: “Free forever” vs “X free messages” is contradictory and erodes trust. I’ll fix the wording to be unambiguous and transparent.
Dashboard, limits & warnings:
Automatic usage limits + email alerts is exactly the direction I want to go. The goal is for users to never get surprised by usage or billing.
Security & publishing hygiene:
Agreed on 2FA for npm publishing already on my checklist.
Landing page trust signals:
Also fair. I’m focusing first on correctness and reliability, but improving the landing page to better communicate intent, limitations, and guarantees is important.
Really appreciate you calling out both the red flags and the potential. Feedback like this helps steer the product in the right direction early, and I’d much rather fix these things now than later.
Thanks again and feel free to keep the critiques coming.
Hi @noel44, this app is interesting! Upvoted!
However, there seems to be a bug in the footer links. All of them are pointing to an unavailable GitHub page (snapshot attached below.
I am sure you will fix it soon cuz even pricing page is leading to this 404 page. A lot of people might be interested in knowing your pricing structure.
Hey@ashok_nayak ,Thanks for catching this - fixing it right now!
Quick question while I build the pricing page: what would YOU expect to pay for something like this?
Thank you so much for the feedback
@noel44 to be honest, it's a bit difficult for me to answer that question. But I will try.
For one domain and an imposed rate-limit (just like APIs), it should be free...
Here it says it's for solo devs, and we all know how solo devs turn their heads away from paid subscriptions, hehe...
I would say keep it free till the MAU touches at least 100 users...but you are the best judge...
@ashok_nayak You're absolutely right, solo devs (myself included 😅) avoid subscriptions like the plague.
Here's what I'm thinking based on your feedback:
Free Forever Tier:
- 100 SMS/month per domain (or 500 SMS/month)
- Email alerts (unlimited)
- Rate limiting: 10 msgs per 5-min window
- Perfect for side projects
Pay-as-you-go:
- Only pay when you exceed 100 SMS/month
- $0.02 per SMS (no subscription)
Does that feel more reasonable? The goal is: free for solo devs, paid only when you have traffic/revenue to justify it. Also, I plan to open source the package and make dashboards for all the errors and alerts (only if this works out😅)
@ashok_nayak Good point! Pricing needs to be regional.
- Free tier should be generous enough for most solo devs (100 SMS/month or maybe 500)
- Email alerts = unlimited and free (0 cost)
- Pay-as-you-go only for high volume
I think this is VERY needed, but not for error checking. I have some notification apps running right now, but I had to set up and go through the Twilio nonsense just to get it to send me a text message when an event happens. Ideally, I'd like to be able to set up multiple numbers to send to. For example, I have an app running to monitor course offerings that open up for my daughter, and we both get a text if one opens. That was a pain, but with your tool, it would have been simple, and I'd pay for it.
@joshua_lippiner1 This is EXACTLY the kind of feedback I need, Thank so much. You just opened my eyes to a much bigger use case.
Feature idea based on your feedback:
Would that solve your use case?
Also - can I email you when I build the multi-recipient feature? Would love to have you as a beta tester since you've already built this yourself.
@joshua_lippiner1 @noel44 This is a great feature but slightly easy to replicate with Twilio. In order to solidify the longevity of your project I would make it open source and charge for hosting similar to apps like n8n. In addition, the recipients feature can be improved to work like a feature flag by binding multiple recipients to one api key. This will allow for updates on the fly instead of having to make changes to the code every time recipients change. In the end the usage would be like:
@noel44 definitely!