Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Billing alarm threshold ($15) is noise — it fires every month around the 3rd

Open
  • Is something wrong?
#412 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
Half a day
Newbie friendliness
32/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
aws
Domain
cloud, devops

Research direction

The alarm awsbilling-AWS-Service-Charges-total is defined in the committed CloudFormation config under server/.ebextensions/cloudwatch-ops-alarms.config, and the issue warns that hand-edits get reverted. Start by confirming the EstimatedCharges threshold there and deciding what the alarm should mean, since the issue asks for a choice between a higher threshold and an AWS Budgets forecast alert. Done means the committed config carries the chosen alarm or budget, the per-resource alarms are untouched, and the change is re-measured against the current run rate.

Written by the indexing model from the issue text.

Description

priority: low tech-debt

Noticed on 2026-10-10 while reviewing CloudWatch alarm state.

awsbilling-AWS-Service-Charges-total is set to EstimatedCharges > 15 USD. Actual spend across the account (RobocodeJs + the other environments in it):
September 2026 total $162.59
2026-10-09, 9 days in $49.32 (~$5/day)

At ~$5/day the alarm crosses $15 on about the third of every month and then stays in ALARM for four weeks. It has been in ALARM since 2026-10-04. It carries no information: it cannot distinguish normal spend from a runaway, which is the only thing a billing alarm is for.

Suggested fix

Raise the threshold to something that would actually indicate a problem — e.g. a level meaningfully above the current monthly run rate — or replace the single flat threshold with an AWS Budgets forecasted-overspend alert, which is designed for this and does not latch for the rest of the month.

Worth deciding what the number should mean first: "spend is higher than I expected this month" is a different alarm from "something is running away right now." The second is better served by the per-resource alarms that already exist (robocodejs-ec2-cpu, robocodejs-ec2-cpu-credits, the RDS alarms).

Context

Some of the current run rate is itself a finding rather than a baseline: the EC2 instance has been consuming billable t3-unlimited surplus credits continuously since ~2026-08-18, because the ladder loop held CPU at 38–42% against a 20% baseline with CPUCreditBalance pinned at 0. #401 and #406 should cut that substantially, so the run rate is likely to drop — worth re-measuring before picking a new threshold.

The alarm is defined in server/.ebextensions/cloudwatch-ops-alarms.config territory; note that hand-edited put-metric-alarm changes get reverted by the CloudFormation alarm definitions, so the change belongs in the committed config (or in Budgets, which is outside the stack).

Related

  • #407 — post-deploy verification includes re-measuring CPU and credits.
Dominant language
TypeScript
Stars
0
Forks
0
Avg merge
8m
Merged PRs (30d)
8

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from LeeAdcock/robocodeJs.com

All issues in LeeAdcock/robocodeJs.com

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.