Skip to content

When something breaks, the first questions are what changed, whether a provider you depend on is down, and whether the answer sits in a system Firefight cannot see. Halon answers all three before it guesses, and you and your own agents can ask the same questions.

What changed is one list, newest first, of everything Firefight knows changed around a resource, a service from the catalog, or the whole workspace. It brings together:

SourceWhat you see
The mapDeploys, settings and status changes a sync saw, and resources that appeared, went away or were renamed
Live updatesA change a provider reported between syncs. When nothing in the activity log explains it, the entry says it was made at the provider directly, such as an edit by hand
FirefightChanges made through Firefight, with who made them. Only people who may read the activity log see these
The provider, read nowFor a resource or a service, its recent builds, deploys and CI runs, read from the provider that runs it

Each entry links to the page it came from. Under the list, Firefight says what it could not cover, such as a connection that is only read at the hourly sync, feature flags kept at a connected product analytics tool, or runs that could not be read and why.

Open a resource in Focus on the map. What changed in its panel starts with the last change the map saw and how long ago, then lists the last week from what Firefight holds. Press Read runs now to read its builds, deploys and runs from the provider as well. That read runs as you, with your permissions, and appears in the activity log. Press Read again for a fresh read.

An incident’s page shows What changed too, for the resources that run the catalog entries named on the incident, from two hours before it was detected or declared until now. It is read again whenever the incident changes, and Read runs now works the same way. You see this panel when you may read the map. When no catalog entry on the incident is linked to a resource on the map, the panel says so, and naming the affected service on the incident or linking that service on the map fills it in.

Ask Halon what changed before something broke, in a chat or in an incident channel, and it reads the list first, for the service you name or the whole workspace, then follows what it points to. Investigations read it the same way.

what_changed takes a resource, a service, or neither for the whole workspace, and a window as minutes (a day by default) or start and end, up to 30 days. It answers the list and what it could not cover. Runs are read for up to five resources.

Firefight knows the public status pages of the providers you can connect and of common outside services, such as payment, email, sign-in, CDN, cloud and AI model providers.

When logs, errors or traces Halon reads show failures calling a provider’s address, such as timeouts to api.stripe.com, Halon reads that provider’s status page straight away and puts what it says beside the result. It says whether the provider reports an outage, its open incidents with their latest update, and what is not fully working, with a link to the page. Halon checks this before blaming your own code.

Over MCP, check_status_page reads a status page by the provider’s name, or by an address your errors mention. Results from search_logs, search_errors and search_traces name the provider and its status page when their failing lines point at one.

Some questions need a system Firefight has no connection to, such as failed logins when sign-in runs through an outside provider. Halon then names that system, says where it saw that your apps use it, and says how to connect it, instead of guessing what it did.

Firefight finds these systems from what is already on the map and in the catalog:

  • A service’s setting named for the system, such as STRIPE_SECRET_KEY
  • A service’s setting whose address is the system’s, such as an issuer URL on auth0.com
  • A catalog entry with the system’s name

A system you can connect comes with a link to connect it under Integrations. One that Firefight cannot connect comes with its status page, and a reminder to describe in the catalog how your team uses it. Over MCP, blind_spots lists them, and category narrows the list to one kind, such as Payments or Sign-in.

ToolRequired permission
what_changedmap: read, plus the read permission of each provider tool it runs
check_status_pageNone. It reads only public pages, and only while web search is on
blind_spotsmap: read