Monitoring and security
Halon can look at your systems without anyone asking. On a schedule you set, it looks for problems that are fine today and will break on a date, such as a disk filling up or a certificate running out, and tells the team that owns them before they become incidents. It also looks into a leaked secret as soon as your code host reports one.
Everything lives on the Monitoring page, under Halon in the sidebar.
Scheduled checks
Section titled “Scheduled checks”A check is something Halon looks at on its own. Add one with Add check and choose what it looks at:
| Looks at | What Halon reads |
|---|---|
| Disk space | Disks, volumes and databases filling up, with the day each runs out at the current rate |
| Certificates | TLS certificates on the domains you run that expire soon or will not renew |
| Error budget | Services spending their error budget faster than it lasts, with the day it runs out |
| Cost | Spend from the billing your providers report, against the months before, with what grew |
| Something else | Whatever your notes describe, such as a queue that should never grow |
Choose how often it runs, every day or every week on a chosen day, and the hour. Times are in your browser’s time zone when you create the check, and the check keeps that zone.
Notes for Halon tell it what matters in your workspace, for example “Only production” or “Our objective is 99.9% over 30 days”. For Something else, the notes are what Halon looks at, so they are required.
Each run reads your connected tools, works out a trend from readings over days or weeks, and lists what it could not read. Run now starts a check at once without changing its schedule. The Last run column links to the run, where you can read every step it took.
Who a check runs as
Section titled “Who a check runs as”Every check has an owner, shown in the Owner column. The owner is whoever created the check, and checks made before owners existed belong to their creator. A check reads only what its owner can: the environments they see on the resource map and the tools they have access to. When something the check looks at is outside that, the run says so plainly, such as “I can’t reach production for this check”, and does not read it. Run now runs as whoever presses it.
When the owner leaves the workspace, the check pauses. The Owner column says “Disks (owned by Sam Rivera, who left) is paused. Give it a new owner to resume.”, and every admin gets the same message in Slack, once. An admin opens the owner menu on the check’s row and chooses Take over to become its owner, or Change owner to pick another member. Either way a message confirms it, and the check runs again at its next time.
A check that has run cannot be deleted, so its runs stay readable. Turn it off with its switch instead, and turn it back on at any time. It then runs next at its usual time.
What Halon says, and where
Section titled “What Halon says, and where”Halon says each problem once, with how urgent it is and the day it becomes a problem:
| Urgency | Means |
|---|---|
| Worth knowing | Nothing to do yet |
| Needs doing within weeks | Plan the work |
| Needs doing now | Act today |
A check that finds several problems says each one on its own.
It says the same problem again only when it gets worse, meaning it became more urgent or the day it becomes a problem moved noticeably closer. A problem it has not seen for two weeks that comes back counts as new. Everything else stays quiet, so a forecast that shifts by a day does not post every morning.
The message goes to the channel of the team that owns what it is about. Halon looks up the resource in the catalog and uses the service’s own notification channel first, then the channel of the team that owns it. A problem with no owning team, such as your cloud bill, goes to the Monitoring channel you choose on the page. With neither set, the problem waits on the page and is said once there is somewhere to say it.
What Halon raised lists every problem, newest first, with when it was last said and how often, and why one is still waiting. Add the Firefight app to a channel if a problem shows that Firefight could not post there.
A workflow can raise a problem too, with its Raise a notice step. It lands in the same list, is said once and again only when it gets worse, and goes to the owning team’s channel, else the channel of the team that owns the workflow, else the monitoring channel. A workflow can also start when Halon raises a problem or one gets worse.
A Cost check reads spend from the providers that report it:
| Provider | What Halon reads | What the connection needs |
|---|---|---|
| AWS | Cost Explorer, by day or month and by service | ce:GetCostAndUsage on the access key’s policy |
| Azure | Cost Management, by day or month and by service, for each subscription | The Cost Management Reader role |
| DigitalOcean | This month so far, by product, and the months before | The billing:read scope on the token |
| PlanetScale | Invoices and their line items | Nothing extra |
| Vercel | Charges by day, service and project | A token whose role on the team can see billing |
| Northflank | Charges by day or month, by kind (CPU, memory, storage, GPU and more) | Billing read on the token’s role |
| GitHub | An organization’s billing usage by product and repository, on GitHub’s enhanced billing platform | Organization administration read for the Firefight GitHub App |
| Trigger.dev | The cost of each run, by day and task, for an environment’s newest runs | Nothing extra |
| Cloudflare | Billable usage by service and zone, and billing history | Billing Read on the token |
AWS charges your account for each Cost Explorer request, so Halon reads it once a run and works from that answer. The Monitoring page lists which of your connected providers Halon reads spend from and which it cannot, and a cost check says the same rather than calling a bill flat.
Leaked secrets
Section titled “Leaked secrets”When GitHub’s secret scanning finds a secret in one of your connected repositories, Halon starts on it at once. It works out what the secret reaches, reads what was done with it, and proposes how to revoke and replace it, in the channel of the team that owns the repository, else the monitoring channel. With neither set, it still looks into it, and you read what it found from the alert’s row under What Halon raised. Every change it proposes waits for a person to approve it.
A secret found in a public place is marked Needs doing now, and any other Needs doing within weeks.
Halon looks into each alert once. If GitHub later finds the same secret in a public place, Halon looks again.
Turn this off with Look into leaked secrets on the Monitoring page.
Asking about it
Section titled “Asking about it”Halon also knows how to look into credential stuffing and suspicious access, and how to check disks, certificates, error budgets and cost when you ask in a chat. Ask “has Halon flagged anything about orders-db?” and it reads what it raised.
With GitHub connected, Halon also reads a repository’s Dependabot, code scanning and secret scanning alerts when you ask, and can dismiss or reopen a Dependabot alert once you approve it. A secret scanning read never returns the secret itself.
Outside agents read the same list with the list_notices tool of the MCP server.
Who can change it
Section titled “Who can change it”Every member sees the Monitoring page. Adding, editing, turning on or off, deleting and running checks, choosing the monitoring channel and the leaked secrets switch need the Monitoring ability, which admins hold and can grant on the Permissions page. Halon’s own runs read what it raised before through a grant to Firefight’s own Halon agent, which an admin can revoke there. Taking over a check or changing its owner is for admins only.