I run two little weather bots. @SierraNevadaWX watches the Sierra Nevada, where I grew up: fires, floods, storms, smoke and quakes. The other one watches King and Pierce County, where I live now, and posts as me. Tonight I sat down to make them a bit quieter. I wanted fewer posts, and only the ones that matter.
Then I looked at what they’d actually been posting, and the honest answer was nothing. Not since about July 8.
Three months of green checkmarks
Both bots run on GitHub Actions. Every few hours a run starts, checks the feeds, posts anything new, and saves a small file of what it has already posted. Every single run since July finished with a green “success.” Meanwhile the Puget Sound bot hadn’t added one new post to its file in three months.
The Sierra bot looked busier, but only on paper. It wrote down new CAL FIRE incidents as “posted” whether or not the post actually went out. The bot was keeping a diary of things it meant to say.
The problem wasn’t that something broke. Things break. The problem was that nothing told me. When a post failed, the bot wrote a line to a log that nobody reads and carried on.
I checked the X keys tonight, and both accounts still sign in fine. So the reason for the silence will show itself on the next real post, and this time the bots will say so (more on that below). I’ll add an update here when I know. (Update: it was the credits.)
A few other things I found
- Six of the seven Sierra river gauges didn’t exist. Only the Tuolumne at Modesto pointed at a real gauge ID. The bot now watches 13 gauges, from Yosemite Valley to the Carson and Walker rivers, all checked against the National Water Prediction Service. All 13 read normal tonight.
- The memory could forget. The “already posted” file kept a random 2,000 entries rather than the most recent, so it could repeat itself. It now remembers things by date and lets go after 45 days.
- My Wikipedia notes were going out as tweets. When a fire starts in Tuolumne County I like to add it to the county’s wildfire list on Wikipedia, so the bot drafted the table row for me. It was posting that draft publicly. Now it opens a GitHub issue instead, which lands in my inbox.
What they post now
The rule I settled on: if you wouldn’t want a friend to text you about it, the bot shouldn’t post it.
| Bot | Posts when |
|---|---|
| Puget Sound | A new warning or watch covers King or Pierce County, or a smoke alert. Elsewhere in Washington, only the big ones: tornado, flash flood, tsunami, blizzard, extreme heat or wind, evacuation, volcano. Earthquakes M3.0 and up. |
| Sierra Nevada | A new warning for a Sierra zone. A new fire at 100 acres (10 in Tuolumne County), then again at 1,000, 5,000, 10,000 acres and up. Serious spotter reports, unhealthy smoke, rivers at flood stage, and earthquakes M3.5 and up. |
What I let go: advisories and “special weather statements,” the temperature roundup every three hours, the twice-daily weather balloon summary, and alerts for Oregon, California and Nevada on the Puget Sound bot (the Sierra bot has those covered). I liked the balloon posts. I’m not sure anyone else did.
One post per storm
The biggest source of noise was the Weather Service itself, in the nicest way. Forecasters update a warning several times as a storm comes in: extend it, add a county, reissue it. Each update is a new bulletin, and the old bots posted every one.
It turns out every hazard carries a tracking code with an event number, so a winter storm warning keeps the same number through all its updates. The bots now post when that number is new, or when the warning spreads to new ground, and stay quiet for the rest. If one storm puts warnings on six Sierra zones at once, that’s one post listing them, not six.
Seattle and Vicinity; Tacoma Area
Until Tue 4 PM PST
Heavy snow. Total accumulations of 6 to 10 inches.
https://www.weather.gov/sew/
#WAwx
There’s also a cap of six posts per run. Anything past that waits for the next run instead of arriving in a burst.
The new Sierra filter got its first test right away. Tonight there were nine extreme heat warnings out across Southern California and Death Valley, and it let every one of them go by.
Telling me next time
This is the part I care about most. Each run now saves its own log into the repository, along with a record of every post it tried and exactly what X said back. I can see what happened from my phone without opening a single Actions page.
And if X ever stops taking posts again, the run fails on purpose, once, so GitHub sends me an email. After that it keeps a quiet note of when the trouble started until posting works again. One email, not three months of silence.
Update, the next morning: it was the credits
The answer came about an hour after I published. I tested my third bot, the twice-daily weather report, and X answered right away: “402 Payment Required: credits depleted.” The keys were fine all along. The developer account had simply run out of API credits, and every bot had been politely failing ever since.
I’m not paying for more just now. So instead of switching the bots off, I put them on standby.
- The alert bots keep watching. Every run they still check the warnings, fires, rivers and quakes, and they write down what they would have posted. Each item gets marked as seen, so if I turn X back on someday, there won’t be a pile of stale alerts waiting to rush out. Turning it back on is one setting, no code.
- The weather report stopped posting. It had been missing most of its posts anyway: it only posted if GitHub happened to run it in the 7 AM or 6 PM hour, which came out to five tries in ten days. And my weather station page already shows live conditions all day. The report’s dashboard still refreshes every hour.
- Streamchaser got the same cleanup. My river bot posts to Bluesky, and it had posted “new 7-day peak” 23 times in three weeks. Most of those were ordinary fall water releases from the dams on the Tuolumne, some as small as 82 cubic feet per second. Now it posts only when a river is doing something unusual for the time of year: high water, the highest flow ever measured on that date, or a free-flowing creek doubling in a storm. While I was in there I found it had never been able to look up those record highs (it was asking USGS for them by the wrong name). It can now.
So that’s where things stand: four bots, quieter and easier to check on, watching the Sierra and the Sound and waiting for when they’re needed. If X ever comes back into the budget, they’re ready.
Alerts from the National Weather Service; river flows from USGS; fires from CAL FIRE and NIFC; spotter reports from the Iowa Environmental Mesonet; smoke from AirNow; river stages from the National Water Prediction Service; earthquakes from the USGS. The original story of the Sierra bot is here.
Go deeper
Wireless Emergency Alerts Explained with Rob Dale — The Alerting Authority, 6 August 2026, about 57 min. An emergency manager on what an alert writer types versus what actually lands on your phone, and why one bad alert makes people switch them all off.
How Do We Know If an Emergency Alert Actually Works? | The Science of Warning Messages — The Alerting Authority, 17 September 2026, about 53 min. Jeannette Sutton and Eddie Bertola with Hugh Walpole on how researchers test whether a warning truly helps people act.
Wildfire Evacuations: Why Your Emergency Plan Might FAIL — The Alerting Authority, 27 August 2026, about 65 min. Tom Cova of the University of Utah on evacuation timing, road capacity and zone-based alerts — very Sierra-foothills relevant.
Botterell, A. & Addams-Moring, R. (2007). Public warning in the networked age: open standards to the rescue? Communications of the ACM 50(3), 59–60.
Hughes, A. & Palen, L. (2009). Twitter adoption and use in mass convergence and emergency events. International Journal of Emergency Management 6(3/4).
Sutton, J.N., Spiro, E.S., Johnson, B., Fitzhugh, S.M., Gibson, B. & Butts, C.T. (2014). Warning tweets: serial transmission of messages during the warning phase of a disaster event. Information, Communication & Society 17(6), 765–787.
Ripberger, J., Silva, C., Jenkins-Smith, H., Carlson, D., James, M. & Herron, K.G. (2015). False alarms and missed events: the impact and origins of perceived inaccuracy in tornado warning systems. Risk Analysis 35(1), 44–56.
Sutton, J. & Wood, M.M. (2025). Opting out: over-alerting and warning fatigue in the era of Wireless Emergency Alerts. Journal of Contingencies and Crisis Management 33(3).
Common Alerting Protocol Version 1.2 — OASIS, 2010; the open standard behind every NWS alert the bots read, updates and cancellations included.
Twitter restores free API access for emergency, weather and transportation alerts — Jon Fingas, Engadget, 2 May 2023; a short history lesson on what paid APIs mean for alert accounts.
NWS API (api.weather.gov) — the free alerts feed at the heart of both bots. · NWS VTEC — the event tracking codes behind “one post per storm.”
National Water Prediction Service — river stages and flood categories. · USGS Water Data for the Nation — the gauges Streamchaser watches. · USGS earthquake GeoJSON feeds — refreshed every minute.
CAL FIRE Incidents — California fires, with CSV and JSON for developers. · National Interagency Fire Center — the national wildfire hub in Boise. · IEM Local Storm Reports app — spotter reports on a map. · AirNow — smoke and air quality from the EPA.
X API pricing — the pay-per-use credits that ran dry. · Bluesky developer docs — where Streamchaser posts.
sierra-alert-bot · nws-alert-bot · streamchaser · weather-report-bot — the code for all four bots. · The original Sierra bot post — where it all started.