Project
InfraAgent
A public infrastructure monitoring product I contribute to at Tasty. My work covers returning-user flows, saved monitoring and wallboard preferences, team access, and database health alerts that catch write failures and disk pressure.
A public product built by the team
InfraAgent is a public infrastructure monitoring product. I contribute to it with the Arvo development team at Tasty. Anyone can use it at infraagent.app, with a hosted service and a self-hostable Next.js and PostgreSQL app.
It monitors websites and APIs, SSL certificates, TCP services, and scheduled jobs through heartbeats. The product records incidents and sends alerts through configured channels. Teams can publish status pages and keep monitoring data separate across organizations.
My work focuses on the parts that affect whether someone can get back into the product, keep their preferred view, and trust a health check when the infrastructure is under pressure.
Getting back to the right place
I improved the returning-user flow across the separate marketing and dashboard sites. A signed-in visitor can reach their monitors directly. When a session has expired, sign-in preserves the protected page and query they were trying to open.
Those entry points had behaved differently. I worked through the homepage and login routes alongside saved dashboard links, so a returning user reaches the right place and an expired session keeps the context needed after sign-in.
Monitoring Settings now stores each user's default Monitors view in their account. I also added separate preferences for the wallboard's appearance, auto-focus, and sound, synchronized with its controls. Preferences belong to the user. One person's changes leave another person's view of the workspace alone.
Access that matches the organization
I corrected Team access summaries and grants to use the eligible apps in the current organization. Stale app IDs and cross-organization grants should not inflate the access shown in the UI or become effective permissions.
The change covered membership and API-key paths as well as the screen. Local database and browser checks used separate users and organizations to verify the difference between a stored grant and access the member could actually use.
A health check has to test the write path
Reads still worked. A database can answer a read query after it has stopped accepting writes, and InfraAgent's old health check could return success in that state while the application could no longer save anything.
I added a write-and-rollback probe so the health endpoint returns a failure when writes are unavailable. I also added database disk-pressure monitoring and alerts before the hosting provider's read-only cutoff, with an admin health screen for the live write-path status and alert configuration.