Product Addresses
Beak products are served from a single platform address, each under its own sub-path — /elm/, /finops/, /m365/, /itsm/, /observability/. Opening a product from the selection screen takes the user to that path on the address they are already signed in to.
Products used to be reached at their own hostnames instead. Those addresses still work: each one redirects to the matching sub-path, so existing bookmarks and shared links continue to open the right product.
Where each product lives
| Product | Path |
|---|---|
| Beak ELM | /elm/ |
| Beak FinOps | /finops/ |
| M365 License Optimizer | /m365/ |
| Beak ITSM | /itsm/ |
| Beak Observability | /observability/ |
A tenant on a custom domain gets the same paths on its own hostname. See Creating a Tenant.
Why products share one address
- One sign-in, no re-prompting — the session cookie belongs to the address, so moving between products on the same address carries the session with it. Products on separate hostnames each needed their own handling to recognise the same user.
- Fewer certificates and DNS records to keep alive — a product on its own hostname needs both, per environment, and an expiry in either one takes that product offline on its own.
- Links survive — a link to a page inside a product resolves for whoever opens it, rather than depending on which hostname the sender happened to use.
What administrators should check
- Bookmarks and saved links keep working — they redirect. Users do not have to update anything, though the address bar will show the new path after the redirect.
- Uptime and synthetic monitoring — a check that asserts an exact URL or expects
200on the old address now sees a redirect first. Point the check at the sub-path, or allow it to follow redirects. - Allow-lists and proxy rules — a rule written against a per-product hostname should be rewritten against the platform address, otherwise it silently stops matching.
Note: Access is unchanged by this. Which products a user can open is still decided by the tenant's product set and then by their roles — see Product Access on the Selection Screen.
Beak Observability collectors and agents
Installed Observability collectors and agents are not affected. They were configured with the product's own address and continue to send telemetry to /api/ on that address, which still accepts it directly rather than redirecting.
There is nothing to reinstall or reconfigure on any endpoint, and no need to reissue agent keys.
Best Practices
- Link to the sub-path in new material — runbooks, tickets and internal wikis written from now on should use the platform address plus the product path, so readers land without a redirect hop.
- Leave the old addresses in place — they cost nothing and they are what every existing bookmark, email and saved report still points at.
- Update monitoring before it pages someone — a redirect-intolerant check is the one thing here that turns a transparent change into an alert.