What has changed

A fuller demo, a new home page, easier setup sharing

30 October 2026

• The demo has data everywhere. Every page and drawer in the demo now shows a consistent fictional company: tasks with their workflow, plan and changes, pull requests with diffs and threaded comments, four releases with scope, gates and a timeline, incidents with their evidence, logs, Sentry, New Relic, Cloudflare and security findings, AI sessions and skills, MCP servers, automations with their runs, Kubernetes, databases and every settings page.
• A new home page. devdash.pro now tells the story of a developer's day, from the daily issues to the screen that answers each one, with real screens of the app you can enlarge or open live in the demo.
• Plan verification. A new workflow step, Plan table (off until you turn it on), checks the work against the approved plan one point at a time. The task's Checks tab shows each point as pass, fail or unresolved with its evidence, so a missing check is visible instead of an empty list.
• A two-column task Overview. The ticket's description, AI brief and comments on the left; its fields, existing work and linked items on the right, each scrolling on its own. Start work moved to the drawer's header, and the note above the tabs no longer says nobody has started when branches already name the ticket.
• Notifications, Favorites and My tasks show their name in the page header instead of "Not found".
• Install and update. The installer waits for the old service to stop and retries loading the login agent, so installing over an existing copy no longer fails with "Could not install the LaunchAgents".

Notification types, pull requests by task, security rules

28 October 2026

• Notifications you can choose. App settings → Notification types has a switch for each thing DevDash tells you about, by section: a review asked of you, a task assigned to you, a comment on it, changes asked on your pull request, critical and high findings, automation runs, and, off until you turn them on, failed pipelines, new Sentry issues and new releases. Before this, only Inbox findings and automation runs reached you. Nothing is announced about what happened before DevDash first looked, an item is announced once however often it updates, and Do not disturb holds all but critical findings.
• Pull requests grouped by task. The list groups by the Jira ticket's status, with each ticket as a row and its pull requests nested beneath it, and a Ticket status filter. The role Reviewed is now Approved by you.
• Comments on the pull request list. A column shows the number of comments, amber while someone has asked for changes or a task is open, so you can see what blocks a merge without opening it. The drawer's Overview lists the latest comments, formatted as Markdown.
• Release scope shows what is merged. The drawer's Contents and Delivery tabs are gone (deployments now sit at the bottom of Build): Scope, which groups by status, now also lists work on the release branch that is not in the release. Its Scope tab marks each issue merged to the release branch, with a PR status filter, assignees as initials and the filters in a panel on the right. Build lists every repository with a release branch to pick from a searchable list, or create from a branch of your choice, kept as soon as it is chosen.
• Release gates you configure. Gates are no longer a fixed list of five checkboxes: Readiness → Gates has Configure gates, where you choose what a release needs, for the whole release or for each repository (or one), switch a gate off for one release, or add one for a single release. A gate can be found from evidence: the files the release branch changed since production (a changelog, docs/**, migrations) or whether the project's monitors are quiet, and a person can still confirm it. A tick records who and when. A release with its work done but a gate open reads Gates open instead of Ready.
• Security rules. Security has two pages, Findings and Rules. Rules lists what the check looks for; add your own (id URL from many places, id enumeration, request burst, repeated failures) with their own routes, window and thresholds, and edit, switch off or delete them. The two built-in rules can be edited and switched off.
• Worktree setup and teardown, and devdash heavy. A repository's .devdash.yaml can list setup commands (install dependencies, write the .env) that run in a new task's worktree, and teardown commands that run before it is removed. devdash heavy -- <command> runs a command once a machine-wide slot is free, so a few tests or builds run at a time, not one per worktree.
• AI sessions are filtered with checkboxes for profile, project and model.
• Backups you can move between Macs. Export downloads the .devdash file and shows its key; Restore has a file chooser instead of a path field and asks for that key. It also takes a .devdash-template file and its key, and applies the template to the current project, instead of answering "not a company file".

Sign in again from the error, clearer Sentry lines

15 October 2026

• Approvals say what they approve. An automation waiting in the Inbox lists when it starts, each step it will take and its workspace, instead of claiming it changes code.
• Refresh on the pull request list. A Refresh button in the toolbar asks the forge for the real state of the open pull requests on the list and stores it, so merged ones leave the Open stage together, not one at a time as you open them.
• Pull request drawer. Builds are their own tab instead of a block in the Overview, approvals appear once (the reviewers in the facts column now use the live read), a pull request merged since the last sync shows as Merged and is stored as merged, and the ticket's description is formatted instead of raw Markdown.
• An automation icon on pull requests and tasks. The lists get a narrow column with an icon on each row an automation has run on: green when the run completed, red when it failed, spinning while it works, with the rule and time on hover. It appears while a rule that listens for that kind of event is enabled.
• Run a rule on past pull requests, and keep its review on the pull request. A rule's drawer has Run on past events…: pick a period (24 hours to 30 days), see how many pull requests match its triggers and conditions, and run it on them, each once. A pull request's detail shows an Automated review section with what each run wrote, kept in DevDash and never posted to Bitbucket. Also fixed: Test match looked only at the latest 100 events of every kind, and stored events had the pull request's author blanked, so conditions on it never matched.
• Built-in review skills. AI → Skills lists pr-review, pre-pr and post-pr, which come with DevDash: review a pull request, check your own branch before opening one, and handle review feedback and the follow-up after a merge, with a checklist per stack. Add to profile copies one into a Claude Code profile, and an automation's AI prompt can then use it.
• Skills. AI → Skills lists every skill on this Mac (your profiles', plugins' and repositories') with filters and search, opens one to read its instructions, and makes new ones: a skill written into a Claude Code profile's skills folder, so it works in a terminal too, with Edit for your own. An automation's AI prompt can pick a skill from the profile it runs as, and the run is told to use it.
• Pick a model, never type one. The model of an automation prompt, a task plan review, an agent profile and a workflow step is a dropdown: Claude Code or Codex, then that system's models (Default where the CLI's own choice is fine). A system a form can't use, such as Codex in an automation, is listed with the reason. The repository section of an automation shows only when an AI workflow or a task plan needs one.
• Automations: conditions that fit the trigger. A rule's conditions and If branches now offer the fields of the event it listens for: the author and branches of a pull request, the level of a Sentry issue, the severity of a Cloudflare, Kubernetes or security finding, instead of a Jira status for everything. The editor offers only the actions that fit the triggers (a task plan for Jira events and schedules), the triggers are one grouped menu, each trigger has its own conditions inside its card (a pull request and a Jira task in one rule are filtered by their own fields), and Save refuses a field a trigger does not have. The editor opens as a side drawer, with Back and Next pinned at the bottom; the repository and branch moved to the Actions step, where they apply, and "enable after saving" to Review.
• Sign in from an expired-sign-in error. When a Kubernetes context's sign-in has expired, the error (on Timeline, Home, Inbox, Releases and the Kubernetes pages) has a Sign in button. It runs the context's own sign-in, aws sso login --profile <profile> or gcloud auth login, in a DevDash terminal so the browser step and any code are visible; press Retry when it finishes.
• Related, from a log line. A line's drawer has a Related section: the incidents open around that time (the ones naming the line's service first) and the deploys and releases in the hour before it. A log alert's firing history links each firing to its incident, and a single open incident can be opened straight from "Firing now" on the Timeline.
• What happened, in order. An incident's drawer lists its start, its end and the strongest related items in the order they happened, with how long before or after the start each one was.
• Tasks of your own, and where each came from. New task on the Tasks page makes a task with no ticket, in a repository, with its branch and worktree. It can be a task or an epic, and has a status, priority, assignee (you, a person or an agent), tags, start and due dates, an estimate, a parent, and comments; epics hold tasks that hold sub-tasks, with progress on the row. Start work on such a task runs the workflow in its worktree.
• Chat on an epic. An epic has a Chat tab: tell Claude Code what you want (“review the incidents screen and break it into tasks”) and it reads the code, creates and updates the tasks under the epic, and works in the epic's own worktree. Edits and commands wait for your Allow, Always allow or Deny; pushes and pull requests are never done from the chat. Every row shows an icon for its source (Jira, a forge, you, an automation, the project chat), and Source is a filter. A row in progress or in review is no longer filed under To do.
• Easier epic drawer. A task's fields fold to one line so the chat has room (All fields opens them again). A Tasks tab shows what is under an epic or a task, with progress, status, priority, assignee and due date, and a New task button. The chat's plan is shown as formatted text in the chat and under Plan and notes; the chat input is one line that grows and stays at the bottom, the thread follows the answer, and an answer is no longer shown twice. The chat no longer starts sub-agents or plan mode. Tab labels line up with the content in drawers.
• Chat survives a restart, and a dev instance for DevDash itself. When DevDash restarts during a chat turn, the chat says so and offers Continue (the conversation is kept). Working on DevDash with DevDash no longer needs the DevDash you chat in to be restarted: an epic's Environment tab runs a second DevDash built from its worktree (own port, own data), and the chat is told never to restart the one it runs under.
• Review a security finding with AI. A finding's drawer has a Review with AI section. It reads every request to the URL over the last two weeks and what each IP did on the whole site (data calls answered, pages, redirects to sign-in, blocks, referring sites), counts them, and an agent says whether several places really opened the link, who got the data and what is most likely. Click an IP in a finding to see what it asked for. The Security list has a Country filter, searches IPs, and shows when a finding was seen from first to last with times.
• A chat for the whole project. The chat button in the top bar (or ]) opens a chat on the right of every page, and it stays open as you move between pages. It is one conversation per project, kept with the project, and it has a name you can change. It knows the whole project: it reads every task and the repositories, searches what DevDash has seen (tickets, pull requests, deploys, incidents), and makes and updates tasks and epics, asking before it edits or runs anything and never pushing. The button shows when it is working or waiting for you.
• Centrifugo in Logs. A new Centrifugo source reads a real-time server's state through its server API: one line per node and pull with clients, users, subscriptions, channels, uptime and memory, so connections can be charted over time, and a warning when a node restarts or leaves the cluster. Its own log is read with the Docker or Files source.
• New projects have workflow steps. A new project starts with the default steps and their prompts instead of an empty workflow that could not be saved, and a project that has none is given them.
• Tasks follow Jira's statuses. The Tasks list groups by the Jira status (Code Review, Failed QA on UAT) in the order of your Jira board's columns, and the board view has one column per status. A status the board doesn't list follows the rest.
• Database connections. The add/edit form is two columns and shows the Test result in the footer, so it stays in view. A MySQL or MariaDB connection with a database set lists only that database's tables.
• Sentry lines in Logs show the issue. A Sentry line reads as the issue's title instead of error.seen.
• Steadier failures. Delivery keeps its numbers on screen when a refresh fails and offers Try again; Kubernetes namespaces open from the keyboard; failed alert-state writes no longer repeat a notification.
• A code on the pairing dialog. Requesting access from a browser shows a four-digit code, and the dialog on your Mac repeats it. Allow only when they match.
• Tighter checks. A database connection's address (a Mongo URI, a Manticore URL) is refused when it carries a user name or password, since those belong in the User and Password fields and the keychain. A database console can no longer call set_config, an HTTP check no longer sends its headers to another host after a redirect, a test attachment cannot be read through a link out of its folder, and a ping target cannot be read as an option.
• Safer MCP and links. Listing an MCP server's tools starts it only when it is enabled in the project, and a link in a follow-up opens only when it is http or https.

Help and tours, approvals from your phone, agents in containers, incident response

12 October 2026

• Stacked drawers. A task, pull request or release opened from inside a drawer opens on top of it instead of replacing the page: the page and the drawer under stay, show as a strip, and a trail under the header takes you back one level or all the way.
• Data explorer tables. Drag a column heading's edge to resize it; the arrow on a heading shows its values as a date, JSON, PHP serialized as JSON, Base64 text, ✓ / ✗, or a host name or IP as flag, address, city and country, in the grid and in the row drawer. Widths, formats, starred tables and saved filters and queries are kept with the project, so a new browser starts the same. Cells show up to 32,000 characters (4,000 before), so long serialized values can be read and formatted; a reload shows a spinner over the dimmed rows.
• Release Build. A Build tab on a release walks it to production: the release branch off production, the tasks you choose (filtered by status, ticked by hand) put on it as a pull request each or as squashed / cherry-picked commits, reviewers, review, and the release pull request merged into production. Source also has New branch and New pull request.
• Data explorer. Services → Databases browses PostgreSQL, MySQL, MariaDB, Manticore Search, SQLite files, Cloudflare D1, Snowflake, Redis and MongoDB read-only: a tree of schemas and tables, rows with sort and filters, columns and indexes, and a query box (SQL, a Redis read command or a MongoDB JSON query) with its history. Connections are added in Settings → Databases and listed under Databases in the sidebar; a connection string can be pasted to fill the fields (also in the Database integration); passwords and keys stay in the keychain.
• Stripe events in Logs. Add a Stripe events source in Logs → Sources with a restricted key (Events: Read). Payments, invoices, subscriptions and disputes arrive as lines, failures as errors, with a link to the dashboard.
• Delivery. Work → Delivery shows how fast and how safely changes reach production over 7, 30 or 90 days: deploys per week, lead time from a pull request opening to production, change failure, time to recover, and the agents' pull requests against the rest with their estimated cost. It is read from what DevDash has already synced.
• Kubernetes Overview. Services → Kubernetes opens with an Overview you read on request: how many pods, workloads and nodes are well, what needs attention (crash loops and what killed them, pending pods, failed rollouts, not-ready nodes, pods that keep restarting), each node's CPU and memory, the pods using the most against their limits, and each namespace in a row. CPU and memory need metrics-server in the cluster; without it the rest still shows.
• Kubernetes logs read as a table. A pod's lines are a table of time, level and message with a column for each field that varies, the fields repeated on every line said once, and a multi-line error kept as one entry. Raw shows the text. The pod's facts sit in three columns, and a connection to a cluster that dropped (sleep, a VPN change) is retried instead of failing until restart.
• Integrations by kind. Project settings → Integrations is split into Work, Monitoring, Data and Communication, with how many in each are connected.
• The app loads on the first try after a bad deploy. The installed app's service worker no longer keeps a page served in place of a missing file, so a stale copy of a stylesheet can't break the app on every load. demo.devdash.pro now sends browsers to the demo.
• Snowflake. Connect Snowflake in Project settings → Integrations with a key pair (the private key stays in the macOS keychain) and add queries the way you do for a MySQL or PostgreSQL database: their rows become Watches. It reads every 15 minutes by default, since each read wakes the warehouse, and has its own connection, so a Drupal watchdog in MySQL and a Snowflake table can be watched side by side.
• Query console. Query console on the Database and Snowflake cards runs one read-only SELECT and shows the first 500 rows, with the schema beside the SQL and Copy as CSV. ⌘↵ runs it.
• Faster. The app's first download is less than half what it was, and the web app now uses the React Compiler. Live opens in a fraction of a second however many watch rows have piled up, and the Timeline reads its sources side by side. When macOS is waiting for you to allow Keychain access, pages say so within seconds instead of loading forever.
• Terminals come back after any number of restarts. Restore used to offer a group's terminals only until the next restart, and since DevDash closes its terminals cleanly when it stops, often not even then. Terminals open when DevDash stops now stay restorable until you restore them.
• A new look. Pages sit on one sheet over a grey background, cards have small corners and real depth, buttons are ink instead of indigo so colour means status, and the type is IBM Plex. Home opens with what needs you beside a strip of the last 24 hours (deploys, errors, incidents), and raises the one item that needs you first, with why it is yours.
• Ask for a command in a terminal. Press ⇧⌘K in any terminal and say what you want; a small model on your Mac answers with one shell command that uses your usual contexts, namespaces and flags, learned from your shell history. You read it, edit it if needed, and insert or run it. Download the model once in App settings → Local model; nothing leaves your Mac.
• GitHub. Connect GitHub in Project settings → Integrations with a token for one organization or user. Its pull requests join Pull requests, with activity, the diff, checks and reviewers in the drawer, and you can comment, approve, ask for changes and merge from there. GitHub Actions runs are pipelines on the Logs timeline and the repository pages, a failed run can start an automation, and deployments line up with releases and errors. Follow-ups can watch GitHub reviews and conversations. GitLab merge requests are now labelled as GitLab's, not Bitbucket's.
• Where clients are, in Logs and Cloudflare. With IP geolocation installed, new log lines with a client IP get their country and network, so Logs can filter by Country and Network. A Cloudflare issue's firewall events show each client's place and network, and security findings name networks from Cloudflare even without the databases. With the city database, a security incident's IPs are also shown on a small map.
• Help and tours. The ? button in the top bar opens the help for the page you're on, with search across all the docs, every guide, a Getting started checklist and What's new. Tasks, Incidents, Automations, the Logs timeline and a task each have a short tour, offered the first time you open them.
• Task drawer. The header shows the ticket key, which opens the ticket in the tracker, and a Refresh button; archiving and deleting a task are in its Details. The title and fields sit at the top, label and value on one line, above the tabs, and each field leads somewhere: the parent opens its task, and status, priority, type, people, project and release open Tasks filtered to that value. A drawer name too long for the header slides by on hover.
• Markdown. Descriptions, plans, agent answers and READMEs render tables, nested and task lists, strikethrough and links properly. A table can be sorted by any column and, when long, filtered.
• Settings moved. The decision model has its own section, Project settings → Decision model. Automations' pages each have their own address (/automations/runs). IP geolocation, shared by every project, is in App settings.
• Filters. A filter that takes one value at a time, such as Release, is now a dropdown; the others stay tick-boxes.
• Decision model settings (Project settings → Decision model) show the connection once connected, with Test, Edit connection and Disconnect, instead of asking for the key again; the switches save as you flip them.
• Approve from your phone. Pair a phone in App settings → Remote approvals and decide runs and automations that wait for you from anywhere, end-to-end encrypted through a relay, with an optional notification when something new waits.
• Agents in a container. A workflow can run its agent steps in Docker, seeing only the task's worktree. Set it up in App settings → AI → Containers.
• Agent outcomes. Automations → Outcomes shows how much of the agents' work lands: runs that end done, pull requests merged, cost per merged pull request and time to merge.
• Incident response and postmortems. Acknowledge an incident, track where the response stands, add notes on its timeline, and draft a postmortem (with AI when it is on) to copy or post to Jira.
• Webhooks. A rule can start when a script, a git hook or a deploy tool on your Mac calls its webhook URL, with what it sends. Make them with Webhooks in Automations.
• Start a rule when CI fails. A new CI failed trigger starts a rule when a Bitbucket pipeline fails, in one repository or any, with the build's branch and commit.
• Investigate incidents. Ask Claude Code or Codex about an incident from its drawer; it gets the incident and what changed around it. With the decision model's new Incident investigations feature, a new incident that looks like a code fault is investigated on its own, at most five a day.
• Fix a Sentry issue with an agent. Fix with agent in a Sentry issue's drawer starts work on its Jira ticket, with the stack trace in the task notes. A new Sentry issue trigger starts a rule when an issue is new, comes back or escalates.
• Act on pull requests. Approve, comment, request changes, post an AI review's findings and merge a Bitbucket pull request from its drawer. In a task, Address review comments turns the reviewers' comments into a new version of the plan.
• Write back to Jira. Move a ticket by clicking its status in the task drawer (the moves Jira's workflow allows), assign it to yourself, comment on it, post a plan version to it, and link the pull request on it.
• Decision models: Jev or Cloudflare Clef. Choose Cloudflare Clef-flash, Clef or Jev in Project settings → Decision model. Inbox triage now runs on its own and labels each item (Reply needed, Review requested, Blocked, FYI), pinning the ones that ask you to act; a new plan-change check skips re-planning when a ticket edit changes nothing. The per-click Jev checks on tasks and releases are gone; a not-started issue shows the branches that already name it instead.
• Task drawer. A started task no longer shows as not started when the project has several repositories. The header says where the work stands, the description shows at once, Accept and implement sits at the top of each plan version, a closed issue warns before Start work, and a disabled Open a pull request says why. Deployments are linked only through the task's own commits.
• Mute a monitor. Silence a noisy monitor for an hour, a day, a week or until you unmute it, from its ⋯ menu or drawer. It keeps its incidents but sends no notification and starts no automation.
• Live pods in Kubernetes incidents. A Kubernetes incident shows each affected pod as it is now: its containers, restarts, last exit and recent events, with links to the pod.
• Install the app. DevDash can be installed from Chrome, Edge or Safari as an app with its own window and Dock icon, and opens without an internet connection.
• DevDash in the menu bar. A server icon beside the clock shows whether the service runs. Its menu has the version, uptime, syncing projects and this Mac's CPU and memory, and opens DevDash, starts, stops, restarts or updates the service, and shows its log. The installer adds it at login.
• devdash start, stop, restart and logs. Control the service without launchctl, and read or follow its log with devdash logs -f. devdash status also shows where the log is.
• devdash call and devdash ops. Call any operation of the service from a terminal or a script and get JSON back: devdash call projects, devdash call task -a id=PRJ-12. devdash ops lists the operations, and devdash ops <name> shows one's arguments and result. Calls are signed with the pairing key, so they work only on your Mac.
• API reference. devdash.pro/api documents every operation, generated from the service itself, with an OpenAPI description for API tools and client generators.

Incidents, Kubernetes and a new sidebar

11 October 2026

• Sidebar. Sections run Work, Monitoring, Terminals, Automations, AI and Services, then Repositories. My Tasks leaves the sidebar: its links open Tasks with Whose work → Mine. Notifications is the bell in the header, and Favorites has no sidebar item. Monitoring lists Incidents, Monitors, Logs (Explorer, Dashboards, Alerts, Watches), Uptime & tests and Security, then Sentry, New Relic and Cloudflare; each of those groups unfolds only while one of its pages is open.
• Incidents. Monitoring → Incidents (g o) lists every incident from Sentry, New Relic, Cloudflare, Kubernetes, the security check and your own checks and log alerts, over the last 24 hours to 90 days. Filter by source, severity, status, monitor, environment and app; Firing now shows only the open ones. An incident opens in a drawer on the right with its metric, the related items ranked, its log lines and Explain with AI. Old incident links open the same drawer.
• Overview is now the Logs timeline. The timeline and its log lines are Monitoring → Logs → Explorer (g l); old Overview links open it there. The incident bands and labelled bars above the chart are gone: incidents are listed on Incidents, and hovering the chart names the ones in a bucket. Show on Overview is now Show on Logs.
• Inbox is a list pane and a reading pane, like a mail client. A dropdown picks the category (All, Needs attention, Approvals, Assigned to me, Reviews, Releases, Chats, Follow-ups, Reports), and Inbox, Unread, Snoozed and Archived pick where items stand. Needs you is pinned at the top, the rest grouped by day.
• Home opens with count cards (Firing, Needs attention, Open tasks, Reviews waiting, Releases due, Runs active) and a Monitoring panel with what is firing, worst first.
• Tables. Every table runs the full width of the page, and a row's level is a coloured edge on its left. The View menu in the toolbar holds Columns and grouping, out of the filters column, and pages with several views pick them from a dropdown. On Tasks, priority is the edge, and Needs you says why a row needs you, for example Stuck 85 days in Ready for QA.
• Cloudflare. Issues, URLs, Firewall and Traffic are sidebar pages under Cloudflare, replacing the view switch in the toolbar. Issues are grouped by kind, a URL opens in a drawer with its figures and requests, Firewall starts with a summary and tabs by rule, country, IP, path and network, and Traffic ranks what the traffic is made of. Pages are kept on your Mac until the next check, so they open at once.
• Kubernetes. DevDash finds your kubeconfig and offers to connect it, naming anything that would stop a context from signing in. Services → Kubernetes has Workloads, Pods and Events; a pod drawer shows its containers, events and lines, opens a shell, forwards ports and deletes the pod, and workloads can be restarted or scaled. A check turns crash loops, out-of-memory kills, pending pods, stalled rollouts, failed jobs and unhealthy nodes into monitors and incidents, and a Kubernetes log source follows pods' output into Logs.
• Security. Monitoring → Security lists private links opened from many places and ids walked through one after another, with each finding in a drawer.
• IP geolocation. App settings → IP geolocation downloads DB-IP's free databases to your Mac (country and network, cities optional) and keeps them up to date monthly. Security evidence and Logs lines then show where each IP is and whose network it is on. Lookups never leave the Mac.
• Fewer false security findings. Requests from cloud and hosting networks, and Cloudflare's own Early Hints requests, are no longer counted as a second person opening a link.
• Smaller changes. Watches can be filtered by Type. AI → Stats narrows by Project, Model and Tool in the filters column, with presets. An automation rule's status reads Enabled or Disabled, and its ⋯ menu disables or enables, runs, edits or deletes it. When Sentry rate-limits a token, short waits are waited out and longer ones pause Sentry with the reason shown on its pages.

v9 preview

October 2026

The first preview of DevDash as a hosted interface with a local service. v8, the desktop app, is frozen; its backend carries over.

• A local service, devdash. It runs on your Mac and holds the data, credentials, git worktrees, agent processes and terminals. The browser talks only to it, on 127.0.0.1.
• A hosted interface at app.devdash.pro, built on the same design system as before, in light and dark.
• Install script. curl -fsSL https://devdash.pro/install.sh | sh installs without sudo, checks the download's checksum, starts the service at login and opens the app already paired.
• Pairing. One-time codes from the installer, or the long-lived key from devdash pair; sessions are bound to the site that paired them.
• Your v8 data carries over. The service reads the v8 data folder as it is.

Screens in this preview.

• Navigation. The sidebar groups pages into Work (Tasks, Pull requests, Releases), Services, Monitoring, AI, Terminals and Automations, with each section's pages listed under it. Monitoring runs Overview, Dashboards, Monitors, Logs, Uptime & tests, Alerts and Watches, then New Relic, Cloudflare and Sentry when they are connected. Old links redirect.
• Monitoring. A local log platform: OTLP, Logtail-style JSON and syslog intake, file, Docker and macOS sources, a query language, live streaming (the ▶ button), patterns, dashboards and alerts. Uptime & tests runs Playwright specs and native checks (ping, TCP, HTTP, DNS) as monitors, with incidents. Log sources are set up in project settings.
• Logs pull in other log stores. A Manticore Search table (local or remote; a Manticore running in Docker is found, and the columns are mapped for you), New Relic logs, Sentry error events, AWS CloudWatch Logs groups and Cloudflare (Workers Logs and sampled HTTP requests) (with an AWS profile, SSO included, or an access key) are copied into Logs on a schedule, so one query language, live tail, patterns, dashboards and alerts cover all of them. Each source shows when it last pulled, its lines today and its last error. The provider stream that was Monitoring → Events is now the events source in Logs; Events leaves the sidebar and old links open it there.
• Services. Local: each task's environment (Compose and processes) with start, stop and restart, every Docker container, listening ports with their owners, and this Mac's CPU, memory and disk. New Relic's applications and hosts are under Monitoring → New Relic.
• Timeline. Monitoring → Overview opens on a timeline of every connected system: Sentry, New Relic, releases, Bitbucket pipelines and deployments, watches, log errors, log alerts and DevDash runs, each in its own lane on one time axis. Each lane shows its volume and marks deploys, releases, incidents, new issues and alerts; markers that overlap merge into a count. Pick 1h, 6h, 24h, 7d or 30d, or a custom from and to, or drag across the lanes to zoom. The strip underneath shows a wider window, and you can drag, resize or move the selection with the arrow keys. Hover to see every lane at one moment. Click a bar or a marker to list its events, with links to the Sentry issue, the release, the pipeline run or the provider. Each source's switch and filters are in the Filters column (see Overview filters, below), and everything is in the URL. The sources start folded into one bar per period, each source stacked in its colour with a legend of totals; Show lanes gives each its own lane again. The log lines sit under the timeline on the same page and follow its window, so one set of presets and one Live switch moves both: the same table as Logs, with paging, the line drawer and an Open in Logs link. The log query and the level, service and source filters are in the Filters column. Click a bar, or Show these logs in a bucket's drawer, to see only that period's lines.
• Monitoring → Overview, one environment at a time. The Timeline and its log lines move to their own page, Overview, first in Monitoring (g o), and Dashboards is again the page of saved chart dashboards. An env switcher at the top left picks Production, UAT, Dev or any environment you save, each with its colour, so production errors are no longer mixed with UAT's. An environment is a saved set of the page's filters: which sources show, the Sentry projects and environment, New Relic applications, Cloudflare zones, repositories and deploy lane, database queries, log alerts and the logs query. New filters make that possible: Sentry environment, deploy lane, watch query and log alert, and an Environment facet for the log lines. The first time, DevDash suggests Production, UAT and Dev from what it already sees (Sentry environments, application and zone names, deploy lanes, the environment on log lines, the database host), each with its reason; Create saves them. "All (no preset)" still shows everything merged. The toolbar is one row: env switcher, time range and window on the left; scale, Show lanes, Explain with AI, Live and Refresh on the right. Old Dashboards links to the Timeline open the Overview.
• Overview filters, per source. The Filters column on Monitoring → Overview groups every filter under the source it belongs to, in the timeline's order: Sentry, New Relic, Cloudflare, pipelines, releases, watches, log alerts and Logs. Each group's header has the source's switch (it replaces the Sources list), its colour and its total for the window ("Sentry · 12k events", "Logs · 23k lines"); a source that is switched off folds away and greys out, and the groups you fold stay folded. Every filter's title explains itself on hover, for example "Environment — the environment Sentry tagged on each event; counts are Sentry events in the window". There are many more filters: Sentry release, category (error, performance, metric, uptime), status, assignee and new or ongoing; New Relic host, transaction, incident priority and deployed app; Cloudflare project and deployment status; pipeline result and branch; release project and released or not; watch severity; alert state; and for Logs the source, service, level, environment, host and attributes such as HTTP status. Each filter narrows only its own source. The Logs filters narrow the log errors lane and the lines under the chart together, and the search box at the top is now labelled "Search logs". Environment presets keep all of these.
• Saved filter presets. Filters columns can save their filters as a preset: Save current as…, then pick it from the Presets menu in the column's header. After a change a ring marks the preset's dot, the menu says what changed, and Update saves it. Presets can be renamed, deleted, and one per page can open by default. They are kept with the project, so everyone using it sees them.
• Presets on Tasks, Pull requests, Commits, Branches and Uptime & tests. Tasks, My Tasks, Pull requests, a repository's Commits and Branches, and the Tests, Runs, Uptime checks and Environments tabs of Uptime & tests now have Presets in their filters column. Their filters, grouping and sort are now in the page's address, so links and bookmarks keep them. The first visit to Tasks, My Tasks, Pull requests or Branches after the update brings back the filters and grouping you last used there.
• Explain with AI on the Timeline. Explain with AI, in the Timeline's header, summarises what happened in the window you are looking at. DevDash first builds a short digest on your Mac: each source's volume and biggest spike, the deploys, the top Sentry issues, log error patterns, incidents, watches, releases and runs, and any spike or new issue that started within 30 minutes after a deploy. Secrets and e-mail addresses are removed. The drawer shows that text, and its size, before anything is sent. Explain sends it to the AI you chose in Settings → AI and streams back a summary, the likely causes, who and what was affected, and what to check next. The items it cites link to the Sentry issue, the deploy, the matching lines in Logs or the watch. The answer is kept for 30 minutes for the same window; Regenerate asks again, and Copy copies it.
• New Relic performance. A transaction's chart in a New Relic application now draws its p50 and p95 beside the mean. The application summary lists its slowest database operations and external services, by total time, with their average time and calls; All opens the full list. The Timeline offers two more sources in the Filters column, off until you switch them on: Transactions (p95), a line for each of the five slowest transactions, and Hosts (CPU), a line for each of the five busiest hosts. New Relic keeps this data for 8 days, so a longer window shows its last 8 days.
• Monitors. Monitoring → Monitors lists every monitor in one place: Sentry's error, metric and uptime monitors (or its metric alerts, uptime monitors and issue alerts on older Sentry), New Relic's alert conditions, and DevDash's own checks and log alerts. Each row shows its status, what it watches and its condition, its last incident and how long ago, and how many incidents it had in 14 days. Filter by source, kind, status and app in the Filters column. A monitor opens with its metric over 24 hours or 7 days, the threshold drawn across and each incident marked, and its incidents with how long each lasted. Sentry and New Relic are read every five minutes, or now with the refresh button in the toolbar; when a token can't read some kind of monitor, the page says which. Sentry metric and uptime issues are tied to the monitor that raised them.
• Incident view. Open any monitor's incident (from the Monitors drawer, a Sentry metric or uptime issue's "Open incident", or a New Relic incident or log alert in the Timeline) to see what else happened around it, across every integration, ranked. DevDash reads two hours before to an hour after (±30m to ±6h, or a custom range) and compares each thing with the same time the day before: deploys, pipelines and releases; Sentry issues that are new, regressed or spiking; Cloudflare 5xx; New Relic transactions whose p95, error rate or throughput moved, busy hosts and slow database or external calls; other monitors that fired; new or growing log error patterns; and watch findings. Each gets a score from 0 to 100 with its reasons in words, such as "deploy 18 min before", "p95 ×3.4 vs yesterday" or "same route /api/v1/orders", and a sparkline against yesterday. The page shows the monitor's metric with its threshold and the incident shaded, a strip of the top items in time, the ranked items by type, and the window's log lines. Filter by type, source and minimum score. Explain with AI centres its summary on the incident and cites the top items. A source that can't be read says so, and the rest still rank.
• Monitor incidents on the Overview. Every incident from Sentry, New Relic, DevDash checks, log alerts and the security check is a band across the Timeline, red for critical and amber for warning, with a strip of labelled bars above the chart ("/api/v1/orders response time · critical · p95 6,014 ms > 6,000") that open the Incident view. While one is open, Firing now above the chart counts them with the worst severity and filters to them in one click. A Monitors switch and source, severity and monitor filters sit in the Filters column, environments keep only their own monitors, and Explain with AI lists them as M1, M2…. Each Timeline source now has a colour of its own in light and dark (log errors and Sentry no longer look alike); red and amber are kept for incidents and thresholds, and a failed pipeline or run is an outline.
• Show on Overview. A monitor's drawer and its Incident view can draw its metric (for example Sentry's p95 span.duration for /api/v1/orders) on the Overview, on its own axis in its unit, with its critical and warning thresholds. Up to four can be shown; remove one from the legend, and environment presets keep them.
• Monitors and incidents, more exact. Incidents end when Sentry or New Relic closes them, and a monitor with an open incident shows as critical or warning. Sentry metric incidents, including those of metric alert rules on older Sentry, carry the value Sentry evaluated. Monitors keep their warning threshold, drawn in amber beside the critical one on the Incident view and monitor charts. A security incident links to its finding (Open finding), and the Incident view's Back returns to where you came from.
• Logs. The environment filter, the Environment facets and environment suggestions also read OpenTelemetry's deployment.environment and deployment.environment.name, on the line or its resource. Jira lines name the issue and what changed (PAY-821 — Checkout retries fail · status To Do → In Progress · assigned to Ana) instead of only jira.issue.updated. The Saved views menu is gone: your saved views move into Logs presets the first time you open Logs. Export is under ⋯, the time range is on the left, and on a phone each line is a card.
• Sentry. Connect Sentry with an auth token in project settings, and Monitoring → Sentry opens at once: DevDash keeps a copy of the unresolved issues, synced every two minutes, and the toolbar says when it last synced (Refresh syncs now). Issues show one per line: level, title and culprit, project with its framework's icon, trend, events, users, when last seen and the Jira ticket; on a phone each is a card. The Events view lists error events newest first, filtered by level, environment, release and project, and an event opens with its exception chain, stack, breadcrumbs, tags, request and user, and a link to its issue. Resolve, ignore for a while or until more events arrive, unresolve, assign and bookmark issues from a row, from several selected at once, or from the drawer, each after a confirmation. Create a Jira task from an issue, or link an existing one, and it is linked in Sentry where Sentry's Jira integration allows. Investigate asks Claude or Codex about the issue in the repository that matches its Sentry project, with the stack and breadcrumbs, and streams the answer into the drawer. The sidebar lists each Sentry project with its framework; inside one, the project filter steps aside.
• Watch details. Click a row in Monitoring → Watches, or press Enter on it, to open it in a drawer: severity, the query that produced it, first and last seen, how many times, a 30-day chart and the latest 50 occurrences. Expand an occurrence to see its type, entity, actor, link and the raw columns the query keeps. Open source query takes you to the query editor, and you can copy the fingerprint, the message or an occurrence.
• Database queries. A connected Database integration (MySQL, MariaDB or PostgreSQL) lists its queries in project settings: each one's last run, rows today and last error, with a switch to pause it. Add one from a preset (Drupal watchdog, Commerce orders, failed queue jobs) or write your own SELECT, with the database's tables and columns beside the editor (click a name to insert it). Test runs it on the real connection and shows up to 20 rows and the events they would become; then you pick which columns are the cursor, timestamp, message, severity, type, entity, actor and link. Changing a query's name or columns keeps its place; changing the SQL or the cursor reads again from the start. Watches links to the editor when it is empty.
• Connected integrations show a summary. In project settings → Integrations, a connected integration shows its status, account, last sync, last error and saved settings, with "Stored in Keychain" in place of the secret, instead of the whole connect form. Edit connection opens the form in a drawer with the saved settings filled in; leave the password or token empty to keep the stored one. Connecting a new integration uses the same drawer, and the setup help folds under "How to set this up". A database's queries list stays in the card, and Add query opens a drawer that starts with the presets.
• Cloudflare. Connect Cloudflare in project settings with a read-only API token, your account id and, if you like, the zones to read. Monitoring → Cloudflare shows each zone's requests, 4xx and 5xx rates, cache hit ratio and edge time to first byte, and each Worker's requests, errors and CPU time, for the last hour up to 30 days, with Pages and Workers deployments marked on the charts and listed underneath. Filter by zone and Worker in the Filters column. Releases list Cloudflare Pages deployments of their repositories under Delivery, and Logs can pull Workers Logs and a sample of HTTP requests. The token needs three permissions: Account › Account Analytics: Read, Zone › Zone: Read and Zone › Analytics: Read. Zone › Logs: Read is not needed, because request logs come from the analytics API. When you connect, DevDash checks which products your token can read and your account uses (zone traffic, request logs, Pages, Workers, Workers Logs, Worker analytics) and reads only those. Pages and Workers are read only if the account uses them and the token also has Cloudflare Pages: Read, Workers Scripts: Read or Workers Observability: Read; otherwise they leave no "missing permission" errors on the Cloudflare page, the Overview timeline, release Delivery, Logs or the sync. The integration card shows what the connection reads, Test checks again, and you can untick a product to stop reading it. Connections made earlier are checked on their next read.
• Cloudflare shows problems, not just totals. Monitoring → Cloudflare now opens on Issues: every five minutes DevDash compares each zone's last hour with the same hour yesterday (or the median of the last seven days, on plans that keep a week) and lists what changed for the worse — failing URLs, 4xx surges without scanner noise, origin errors (520–526), slow URLs, cache misses on pages that used to hit, firewall spikes, one IP or network hammering a path, bot traffic, and traffic drops or spikes per host or country. Paths with ids, UUIDs or hashes are grouped as :id. Issues stay open until three checks in a row no longer find them, and each shows its impact, when it started, a sparkline against a dashed baseline, its severity and why. An issue opens in a drawer with its breakdown by country, device, data centre, network, browser, method, status and cache, edge versus origin timing, sample requests with Ray IDs, firewall events on the same URL, and links to Logs and the Cloudflare dashboard. A strip above every view shows requests, the 5xx and origin error rates, p95 time to first byte, cache hit ratio and blocked requests against the baseline. Next to Issues: URLs (every path with its errors, timing, cache and change, sortable), Firewall (firewall events by action, rule, country, IP, path and network) and Traffic (the earlier charts, smaller). Filters cover zone, host, path prefix, status, method, country, device, cache status and firewall action, with presets. DevDash reads each zone's plan when you connect and uses what it offers; the page says what a plan leaves out. The same three token permissions are enough.
• Cloudflare issues in monitoring, incidents and automations. Cloudflare's checks are monitors now: Monitoring → Monitors lists one per kind of problem and zone, such as "sequencing.com · failing URLs", and each Cloudflare issue is one of their incidents, from when it opened until it resolved. An issue's drawer has Open as incident. The Incident view brings Cloudflare evidence to any incident: the Cloudflare issues open around it, and for an incident about a URL such as /api/v1/orders, that URL's 5xx, origin errors, p95, cache and firewall events against the day before, with reasons like "same route /api/v1/orders · origin 524 ×12 vs yesterday"; the whole zone's 5xx still counts, but for less. On the Overview, the Cloudflare lane marks the issues it opened, coloured by severity, and a mark opens the issue; new Cloudflare filters narrow that lane only: host, issue type, status class, cache status and firewall action. Explain with AI lists the top Cloudflare issues in the window as CF1, CF2… and links them. Request lines in Logs now carry the Cloudflare data centre too. A new automation trigger, Cloudflare issue opened, starts a rule when the check opens an issue of one type or any, with the issue's title, type, host, path, severity, impact, why and links.
• Security: private links opened from many places. A new page, Monitoring → Security, appears once DevDash has requests to check (Cloudflare connected, or access logs in Logs). Every five minutes it looks for a URL with an id in it (a user id, a UUID, a token) opened from 3 or more IPs or devices within 15 minutes, a sign that a private link leaked or an account is shared, and for one IP walking through 20 or more ids of a route (enumeration). Bots, crawlers, link previews, health checks, static assets and, by default, private addresses are left out; more countries or networks raise the severity. The list masks the id (/share/•••3b2c); a finding's drawer shows the full URL, the IPs, devices, countries and sample requests. Settings change the window, the thresholds and the routes to ignore. Findings are monitors and incidents too, and a Security finding opened automation trigger starts a rule with the URL and IPs masked.
• AI. Every AI coding system on this Mac (Claude Code profiles, Codex, Cursor, Gemini, Windsurf, Copilot CLI, Zed) with usage and cost estimates, sessions and transcripts, skills and agents, and the MCP servers found in their settings, which DevDash can also call itself. Follow-ups check Jira, Bitbucket and Slack (through MCP) for things you haven't answered.
• Scheduled AI reports. An automation's AI prompt can run as one of your Claude Code profiles and read through its claude.ai connectors (Sentry, Jira, New Relic, Slack), with the exact tools you tick and no tool that writes. With "Deliver to Inbox and notify" its report lands in Inbox → Reports with a notification, and "Give it the previous report" lets each run say what changed since the last. A "Sentry daily digest" template sets one up for weekday mornings.
• Terminals. Groups are listed in the sidebar; panes take the full width.
• Repositories. A code browser per repository: source, commits, branches (as a tree), pull requests, pipelines, deployments and work items.
• Drawers open wider, over a dimmed backdrop.
• One table everywhere. Every list (Tasks, Pull requests, Releases, Monitors, Sentry, Cloudflare, Logs, Services, Repositories, Automations, AI, settings and more) now sorts from its column headings, shift-click adding a second key, with the sort in the address and in saved presets; the Sort sections of the Filters column are gone. A Columns section shows and hides columns, and headings can be dragged to reorder or resized at their edge, remembered per table. When a list updates, new rows slide in, moved rows glide into place and changed values flash, unless motion is turned down. A repository's Branches tree is the same table now, with the Columns section, resizable and movable headings, and folders that still open one level at a time with ←/→.
• Agent profiles editor. Project settings → AI workflow & agents lists the profiles terminals launch, with their model, tools, pre-approved MCP tools and open terminals. New, Edit and Duplicate open an editor for the name, Claude Code, Codex or a custom command, the model, instructions added to the system prompt, the built-in tools, MCP tools from your Claude Code servers and connectors, other arguments and environment variables, with a preview of the command it runs.
• Templates and restore. Project settings → Data has "Save as template": it downloads the project's setup (what each integration syncs, workflows, agents, automations, expectations and repositories by remote, never credentials) and shows a key to send separately. New project → "From a template" opens that file with its key, shows what is inside, creates the project, suggests a local clone for each repository (change any of them, or map later) and lists the accounts to connect. Data also has "Restore from backup": point it at a .devdash export, check what it is and when it was made, then type the password and the project's address to replace the project's connections and settings with the backup's.
• Checks start automations. A rule's trigger can be "Tests failed" for one environment or any, or "Monitor down" for one monitor or any, each picked from a list. A "Log alert fired" trigger is there too, and its run gets the alert's name, query, count, window, firing time and a link to the matching lines in Logs; it fires for an alert whose Trigger automations action is on, and the alert lists the automations it starts. A new "Run tests" action queues the tests with a tag against an environment, suggesting the tags your tests carry. Home shows how many checks are down and the open incidents with how long each has been open, or "All N checks up" in green, linking to Uptime & tests.
• All runs. Automations → Runs opens on All runs when no rule is picked: every AI workflow run in the project, including task runs, pull request reviews and the runs a rule starts, with its state, task, current step, the rule that started it and when it started. Filter by state, task or step in the Filters column. A row opens its task on Workflow, a pull request review opens its pull request, and any other run a small drawer. Home's Runs active opens this list on the running, queued and awaiting runs.
• One layout for every page. Toolbars put the time range on the left and the sync status, actions and views on the right. A page that can't be read keeps its toolbar and filters and offers Try again, and partial failures are one line ("2 sources couldn't be read · Details · Retry") instead of stacked banners. Danger alerts are clearly red in dark mode. Filters columns hide values with no matches and empty sections, list up to 12 values before Show more, and clear a section with ×; the Presets button always shows the preset's dot and name. Tables share one row height, and drawers read "Area / name". An incident page sits under Monitoring → Monitors in the sidebar and breadcrumb, Help & resources moved from the sidebar into the account menu, and each repository in the sidebar has its own expand button.
• Calmer pages. Home reads in priority order: what needs attention, your uptime checks ("Paused · no open incidents" with Resume), follow-ups waiting on you, your open work, then delivery; the counts are one row of links, Getting started is one line until it's done, and the Project settings button is gone. On Tasks, the Release filter is a facet with counts, one-item groups fold into Other, Refresh sits on the right (Releases has one too), and My Tasks says "Assigned to you". Automations shows New automation on Rules only, and the paused banner carries Resume. On Uptime & tests, Runs is a Show setting in the filters column and the Monitors tab is now Uptime checks, with a link to them in Monitoring → Monitors. Cloudflare's Security view is now Firewall. AI Stats has the shared time range, MCP's Add server is on the right, terminal panes stack instead of wrapping one letter per line, and Inbox opens with its filters closed.
• Small fixes. Pull requests and releases have a star in their drawers, like tasks, for Favorites. The keyboard shortcuts list shows every G chord, generated from the navigation, so it no longer lists a missing one or leaves some out. Dialogs and editing drawers open with the first field focused instead of the Close button. Home's Recent activity → View all opens Logs on source:events. A template's preview no longer lists a workflow the import does not create. GitHub, which has no integration yet, is no longer offered among the integrations, and Custom events is documented under Integrations.
• Release timeline and live pull request status. A release has a Timeline tab. It shows the median lead and cycle time, how many issues reopened, the time spent in review, and one bar per issue showing the statuses it passed through, with today and the release date marked. You can sort it by key, lead time or cycle time and filter it by status. A pull request's Overview opens with a Live panel: builds and pipelines with their state and duration, approvals, conflicts, and how far it is behind its target. It refreshes on demand, and every 15 seconds while a build is running.