Console.text() – SMS alerts when code executes | Hacker News Reader

Console.text() – SMS alerts when code executes

6 pointsNoel0416 comments

  Hey HN! I built console.text() - a tool that texts you when specific code paths execute in production.

  The idea came from Jason Goodison's YouTube video about micro-SaaS products. I'd been stuck in tutorial hell for months, so I decided to just ship something.

  What it does:

    npm install @holler2660/console-text

    const { init } =  require("@holler2660/console-text");
    init({ apiKey: 'ct_live_xxx' });

    console.text('Payment failed', { userId: '123' });
    // → SMS arrives in 5-10 seconds

  Try it: https://soorajdmg.github.io/Console-text/

  Why this vs Sentry/PagerDuty?

  Those are great for teams. This is for solo devs and side projects who want dead-simple alerts without the setup overhead. If you know console.log(), you already know how to use it.

View on HN

This is a pretty crowded space (Vonage, Clicksend, TopMessage, etc). They all provide very simple SMS sending libraries for JavaScript.

The biggest problem you’re going to have going forward is establishing trust over existing platforms.

You’re absolutely right, SMS itself is commoditized, and there are many solid providers. Console.text() isn’t trying to compete as “yet another SMS API”. The focus is on developer ergonomics and intent, not transport: one-line, code-level alerts (console.text("error")) built for early-stage teams that don’t want to wire PagerDuty / Datadog yet

It seems like my carrier is blocking the messages. The console says it was delivered, but my phone isn't getting anything.

“Delivered” at the API level means the message was accepted by the downstream carrier / aggregator, not that it necessarily reached the handset. In some regions and carriers, especially for A2P traffic, messages can be filtered or silently dropped after that point. we’re actively working on: clearer delivery state distinctions (accepted vs handset-delivered) fallback routing where possible better guidance on sender IDs and content patterns that reduce filtering

If you’re open to it, sharing the country, carrier, and message type (transactional vs promo) helps us dig deeper.

USA, T-Mobile, message was "Error Detected"

Hey Jeremy, did you try: debug:true ie, init({ apiKey: "ct_live_key" ,debug:true}); if yes, what did it show?

% cat test.js

const { init } = require ( "@holler2660/console-text") ;

init({ apiKey: "ct_live_<key removed>", debug: true });

console.text("Error detected!");

% node test.js

[console.text] SDK initialized successfully

[console.text] Alert sent: { id: 'zzmfq6eltuqica32krircrql', delivered: true, rateLimited: false }

  Thanks for the detailed debug output! This confirms what we suspected, the message is being accepted by Twilio but it might be filtered by T-Mobile before reaching your handset.

  Can you try sending "Error Detected" one more time just to confirm it's consistently filtered (not a one-time glitch)?

  If it fails again, then:

  1. The immediate problem: "Error Detected" is likely triggering T-Mobile's spam filter. Try a more specific message like "[YourApp] Error in payment processor at 3:42 PM", generic error messages get filtered heavily. Let me know if that gets through.

  2. Our misleading status: You're right - showing "delivered: true" when it just means "accepted by carrier" is confusing. We're working on:
     - Clearer status terminology ("accepted" vs "delivered")
     - Webhook integration to track actual handset delivery
     - Guidance on avoiding carrier filtering

Again, Thank you so much for testing this out.

Sending "Error Detected" has failed multiple times, including in a re-test now.

Tried changing to "Hey Jeremy1026: Error in payment processor at 3:42 PM", same status with no delivery to my phone number, ID: jz44a46jjpx7vjpzsa9c0soc.

I used to work with Twilio pretty heavily at a SaaS, I left as they started to crack down on SMS. One of my last projects was developing an in-app front-end to submit the regulatory paperwork to get higher delivery rates for SMS. I know it was a huge pain, sounds like it still is.

> Jason Goodison's YouTube video about micro-SaaS products

Can you link the video?

yup sure : https://www.youtube.com/watch?v=Bs29i2TR7AE

interesting

btw - can't connect to any consoletext.dev domain - dashboard, docs, etc

Why not use ntfy.sh?

  ntfy.sh is great! But it requires:
  - Setting up a topic/channel
  - Installing their app on your phone
  - Subscribing to topics
  - Running a curl command or HTTP client

  console.text() is:
    npm install @holler2660/console-text
    console.text('thing happened');

That said, ntfy.sh doesn't do SMS, so if you genuinely need to wake up at 3am for critical alerts, it's push notifications vs actual phone calls/texts. The main thing I'm going for is ease of use

is this cloud-friendly? or just us-based?

It's global! The SDK works anywhere, and you can receive SMS to any phone number worldwide.

Reply on news.ycombinator.com