2021 · Co-founder
JustMonitors
A paid alerts product for sneaker and resale groups. We watched the Twitter accounts that post restocks and early links, and sent each new tweet to our members' Discord servers with the links already expanded.
- Role
- Co-founder. Wrote the monitor, the staff bot, and the docs, and led a support team of three
- Stack
- Node.js, OAuth 1.0a, Discord webhooks and bots, AWS EC2
- Reach
- 80 monthly active users and 6 paying organizations

The accounts and tweets here are made up. The embed layout, colors, footer, and the bot's replies come from the original source.
How it worked
Every half second, the monitor asked Twitter's v1.1 timeline endpoint for the newest tweet from each tracked account. Each request carried an OAuth 1.0a signature, an HMAC-SHA1 over the method, URL, and parameters.
A tweet it hadn't seen went through a short pipeline. The t.co links were swapped for the real URLs, photos and videos were pulled out, and a lock was added if the account was private. Then it went to Discord as an embed with the follower count, the app the tweet was sent from, and shortcuts to the account's likes, profile, and following list.
Eleven API keys
Polling that often runs into Twitter's rate limits quickly. The monitor held a pool of eleven API keys and moved to the next one whenever a request failed. Each switch was posted, with the error, to a separate Discord channel for the team.
Run from Discord
Staff never had to touch the server. A companion bot took commands from anyone with a staff role: .add and .remove changed the tracked accounts, .list showed them, and .setdelay changed the polling interval. The bot wrote to a settings file that the monitor re-read on every pass, so a change took effect within a second, without a restart.
Looking back
The list of seen tweets lived only in memory. Every restart re-posted each account's latest tweet. Today I'd keep that list in a small key-value store and let the monitor pick up where it left off.