What's new

A file that named each error's user as a plain id, such as "user": "u-1", failed with an error page; it's now read as that customer's id. Stack frames written with "filename", "lineno", and "function" are read, and so is a stack trace pasted as one piece of text. The note about what wasn't read now covers what sits inside a user or a stack frame, says where customers, timings, and traces go when they're at the top of the file, and says when the errors' trace ids match none of the spans. A file with no "errors" list is told which of its sections weren't read, beside why it can't be replayed.

An organization's owners now get an email a few days before its Business trial or founding pilot ends, and another when it has ended, so nobody has to be signed in to find out. Both say what the plan you'd be on doesn't include and, where it applies to you, what else changes: how many members can make changes, how many projects stay active, and how many events a month it takes. The billing page and the banner say the same. After a founding pilot, a third email arrives a week before the 30 days its history is kept for run out, and the banner says how far back the plan keeps events from then on.

A security review led to a set of changes you may notice. Signing in through an organization's SSO now opens that organization only; to open another one you belong to, sign in with your password or through its own SSO, and anyone signed in through SSO is asked to sign in once more. Turning on two-factor authentication asks for your password. A project's webhook signing secrets are shown to admins and owners only, and plain-English issue search needs a member rather than a viewer. Email confirmation and reactivation links work once. Repeated wrong passwords are limited for each account, not only each address. The API takes up to 1 MB in a request (16 MB for a source map, 8 MB for a trace, 4 MB for a session replay) and reads up to 2,000 rows of a batch. API keys, webhook secrets, heartbeat and invitation links, and alert destinations are now encrypted where they're stored; none of their values changed, so nothing you've configured needs touching. Signing up now asks you to open the link we email you before you're signed in, and a project's API key and DSN are shown to members, admins, and owners rather than viewers.

The Incidents detected section of a report now ranks your projects by how many incidents each had in the window, with the worst severity among them and the average time theirs took to acknowledge and to resolve, when the report covers all projects. It says how many of your projects had an incident at all, and shows the average time to acknowledge an incident beside the same figure for the window before. All of it is in the emailed report too.

The Dashboards page now offers a ready-made Production health dashboard for whoever runs the team: incidents, average time to acknowledge, average time to resolve, and customers affected across the top, then incidents by project and by severity, the trend over time, and what's still open. Add it with one click and rearrange it like any other. Every big-number widget, on any dashboard, now shows how it compares with the same length of time before it, colored only where lower is plainly better. Incident widgets also gain average time to acknowledge, a sum of customers affected, and a filter for open or resolved.

When you replay an incident from a file of your own and some of it isn't in a shape the replay reads, the result now says so first: which sections and fields were skipped, and where that kind of evidence goes instead, such as a customer's id, query timings, a deploy, or a trace's spans. Before, the result only said that customers, traces, or performance data weren't included, even when the file had them under other names.

Reports counted only missed heartbeats and failed uptime checks as incidents. They now have an Incidents detected section: how many error-rate incidents opened, compared with the window before, the average time to resolve, customers affected, how many are still open, and a count by severity; the emailed report and its summary include them too. Dashboards gain an Incidents data source (count over time or by severity, and average duration), new organizations' starter dashboards include Incidents over time, and events can be grouped or filtered by source, to tell SDK errors from ones read through a read-only connection.

When the likely cause has a point against it, such as a deploy whose changed files are nowhere in the failing stack traces, alerts in every channel and the incident's postmortem now show it, marked Against, as the incident page already did. The webhook's verdict gains counter_evidence and inferred fields. And when the likely cause names an earlier deploy than the most recent, the alert's What changed line, pull request, and comparison link are about that deploy, with the later one listed after it.

An incident's alert goes out the moment it opens, before a deploy's changed files and the first performance readings are in, so the cause it names is an early answer. A rule for detected incidents now has two options, both off unless you turn them on. Tell me if the likely cause changes sends one follow-up, in the incident's first 15 minutes, naming the new cause and what the first alert said. Tell me when the incident resolves sends one message saying how long it lasted; on PagerDuty and Opsgenie it resolves the alert the first one opened. Edit a rule under Alerting, Notification rules to turn either on.

If the process handling incoming errors crashed, the errors it was in the middle of were dropped, and the rest waited about five minutes. Interrupted errors are now picked up again, and a crash is noticed within about a minute.

On a project with hundreds of thousands of events, the Releases page took seconds to load and the issue list's release and environment filters slowed every page view. The Releases page now loads several times faster, and the filters take a few milliseconds however many events a project has.

Most SDKs assumed they were in development unless told otherwise, and only send from production and staging, so following a setup page exactly sent nothing, with no sign of why. Every SDK now reads FORGE_OPS_ENVIRONMENT, then your framework's own setting, and assumes production when nothing is set, and when a DSN is set but the environment doesn't send, it prints one line at startup saying so and how to change it. Also: PHP lets an uncaught exception end the script with its usual error and exit code again, the C++ SDK no longer crashes at a normal exit after reporting, the C SDK sends a reported error without waiting for the next run, the Ruby gem reports from plain Rack and Sinatra apps, and the Perl module installs with a plain cpanm. New versions: Python 0.17.0, PHP 0.8.0, Ruby 0.16.0, Java 0.13.0, Kotlin 0.12.0, Go 0.10.0, Rust 0.14.0, Node 0.17.0, Dart 0.14.0, Elixir 0.15.0, .NET 0.15.0, C 0.8.0, C++ 0.9.0, Perl 0.12.2. Each setup page is updated, including imports some snippets were missing.

If your app already reports errors to Sentry, a project can now read them from there: under Settings, Connections, add a Sentry auth token with only the read scope, and new errors arrive within a couple of minutes as issues, incidents, and likely causes like any others. ForgeOps only ever reads; it can't change anything in Sentry, and the page shows what your token can do. Before importing starts, a review page shows that project's recent error volume against your plan's quota: each imported error counts as one event, the same as from an SDK, checking for new errors uses none, history is never imported, and importing pauses at your quota. Business plan and up, and included in the trial.

Pro was limited to 10 members, so an eleventh teammate meant moving to Business. Every paid plan now includes unlimited members, so adding people never changes what you pay. Free stays a single member.

Clicking Start Free while browsing the live demo opened the sign-up page still signed in as the demo, with the demo's banner and menus around the form. It now leaves the demo and shows the normal sign-up page; the sign-in page does the same.

After visiting the live demo, the Request a language and support pages opened as the demo account, with the demo's banner and its email filled in, and couldn't be sent. They now look and work the way they do for anyone, whether or not you've been in the demo.

The Request a feature page has a new category, Something else, where you name the kind of thing you're asking for in your own words.

Every page of the app now has a Report a bug link at the bottom. It asks three things (what happened, what you expected, and how to reproduce it if you know), and sends along the page you were on, your browser, and your organization and project; if you were looking at an incident or an issue, it includes the likely cause it was showing, so we see what you saw. You can untick Include diagnostic information to leave that out. Reports show up under Account, Support tickets, where we reply. Request a feature sits next to it for ideas rather than bugs.

Until now, an incident's likely cause could only name a deploy if your pipeline reported deploys to ForgeOps. Now, when none was reported, ForgeOps looks at the release your SDK sends with every error: a release that first appeared just before the spike, in a project that had errors from an earlier one, becomes the likely cause, named as a release ("Release v1.42") with a lower match confidence and a plain note that it's inferred from your errors because no deploy was reported. When a deploy is reported for it, that takes over with its real time, pull request, and author.

There's a new way to see how ForgeOps investigates: a replayed incident you step through minute by minute. The example on the site is a checkout incident eight minutes after a deploy, where the deploy is the first answer, loses confidence once its changed files turn out to be nowhere in the failing stack traces, and gives way to a slow query when that data arrives. You can also replay an incident of your own, with no account needed: upload one JSON file of what was recorded around it (errors, and optionally deploys, timings, traces, failures, and metrics) and see when ForgeOps would have detected it, what it would have named at each point, what counted against that, and what it couldn't check. Nothing you upload is saved: the result is shown once, on the page that ran it, and no alerts are sent.

An open incident used to be marked resolved once its errors stopped climbing, even when they had settled at a steady high rate, so a sustained outage could show as resolved about fifteen minutes in while it was still failing. An incident now stays open for as long as its errors are still running at least double what was normal before it began, and resolves once they've been back down for ten minutes.

Read-only connections now include Honeybadger, alongside Sentry. Under a project's Settings, Connections, enter the Honeybadger project's ID and a personal auth token, review how many errors to expect against your quota, and start: ForgeOps reads that project's new errors every five minutes (up to 25 new occurrences of each error per check) and gives you issues, incidents, and the likely cause without installing an SDK. It only ever sends read requests. Honeybadger's tokens can't be limited to reading, and the page says so plainly, so use the token of a user who can only see that project. On Business and above.

Read-only connections now include Datadog. Under a project's Settings, Connections, enter a Datadog service, your site, an API key, and an application key scoped to logs_read_data, review how many errors to expect against your quota, and start. ForgeOps reads that service's error logs that carry an error type and stack trace (the ones Datadog's own error tracking uses) every two minutes and gives you issues, incidents, and the likely cause without installing an SDK. Errors that only exist as APM traces aren't read. It only ever sends read requests. On Business and above.

Replaying an incident of your own no longer starts with building a file in our format. Upload or paste Sentry events, JSON log lines, a CSV with a time column, or plain log lines that start with a time, and ForgeOps works out which it is and picks out the errors. The form also takes what an export can't carry: when a deploy went out, and what your team found. The result shows your team's finding beside ForgeOps's own conclusion, so you can see how the two compare. Still no account needed, and still nothing saved.

A project's install page used to give only Ruby on Rails a command that sends a test error; every other language was told to raise an exception somewhere. Now all twenty have a short snippet to copy, with your project's DSN filled in where it's needed, the flush a short program needs to deliver before it exits, and the environment set where a development machine would otherwise stay quiet. The last step is now called Watch it arrive, and if nothing has arrived after half a minute it lists the usual reasons and what to check.

The Android client (0.12.0) now treats its environment as production unless you set it, like every other ForgeOps client. Before, it counted as development, which doesn't send, so an app that set only a DSN reported nothing and said nothing. When a DSN is set but the environment isn't one that sends, it now logs one warning to Logcat under the tag ForgeOps saying which environment it saw and how to change it. If you relied on the old default to keep debug builds quiet, set the environment to development there.

Two ways a correctly installed client could send nothing without a word. The Elixir client (0.15.1) now logs its Not sending warning the first time it drops an error because the environment isn't enabled, not only when init is called, so an app configured through config.exs or FORGE_OPS_DSN alone hears about it under Mix on a development machine. The Perl client (0.12.3) now installs the two modules it needs to send over https, IO::Socket::SSL and Net::SSLeay, and says so in one line if they're missing; before, it installed cleanly on a perl without them and then delivered nothing.

Read-only connections now include Splunk. Under a project's Settings, Connections, enter your Splunk API address (the management port, usually 8089), the index your app logs to, and an authentication token for a user whose role can only search. ForgeOps reads that index's events that mention an error every five minutes, keeps the ones that are errors along with their stack traces, and gives you issues, incidents, and the likely cause. Splunk only accepts a search as a POST, so that's how ForgeOps asks; it sends one fixed search and nothing else, and changes nothing in Splunk. Splunk Cloud needs its REST API enabled for your stack first, and a Splunk of your own has to be reachable from the internet. On Business and above.

There's a second replay to step through. Two deploys go out four minutes apart, carts start timing out, and the performance metrics that would show why stop arriving just as it begins. ForgeOps names the most recent deploy first; once what each deploy changed is read, the evidence moves to the earlier one, whose changed file is in every failing stack trace, and the result lists the missing metrics among what it couldn't check. As with the first replay, every step is what the rules say about that data at that minute.

When two deploys went out shortly before an incident, the likely cause only ever considered the most recent one. Now each deploy in the fifteen minutes before is weighed on its own: when the latest deploy's changed files are nowhere in the failing stack traces and an earlier deploy's are, the earlier one is named, and its evidence says it isn't the most recent. With nothing to tell them apart, the most recent still leads. Also, a likely cause no longer says there was no sudden slowdown in the database or outside services unless timings were actually being reported for the minutes the incident began in.

Errors sent from one address were limited to 60 a minute, so a busy server, or several behind one outgoing address, could have errors refused during an incident, exactly when they matter most. That limit now applies only to requests with a wrong or missing key, and a project can send up to 3,000 errors a minute. Your plan's monthly event quota still applies.

When a new error arrived several times at the same moment, the way an incident usually starts, two of those occurrences could both try to create its issue, and the one that lost was dropped. It's now counted against the issue that was just created, so every occurrence is kept.

Each error now does about half the database work it did, so a burst is processed about a third faster and alerts go out sooner. Checking whether an error's user is new to its issue used to get slower the more events the issue had; it now takes the same time on an issue with fifty events or fifty thousand.

The likely cause on an incident's page, and in Where to look on an issue's page, now asks "Was this the cause?" with Yes and No buttons. Your answer is saved for the likely cause you were shown, your button stays highlighted when you come back, and you can change your answer later. The answers tell us how often each rule behind the likely cause is right, so we can tune the ones that point the wrong way. Answering takes a member of the organization; viewers see the card without the buttons.

ForgeOps keeps recording deploys while an incident is open, so a rollback or a fix shipped mid-incident shows on its timeline. The likely cause, the deploy named in the recommended action, and the deploy used to find other affected projects now always come from the latest deploy that went out before the incident started. Before, an incident with a deploy recorded after it started could name that deploy, or an older one, or show no likely cause at all.

With GitHub or GitLab connected, a deploy named as the likely cause is now checked file by file against the stack traces of the failures it's blamed for. When the deploy changed a file the failures run through, the evidence says so ("Changed promotion.rb, which is in every failing stack trace"), it's one of the two lines every alert carries, and the match confidence goes up. When the deploy's changes appear in none of the failing stack traces, the card says that too, marked apart from the evidence, and the confidence goes down: it's still a lead, since a config or dependency change can break code it never touched, just a weaker one. ForgeOps also reads a deploy's changes as soon as it's tied to an incident, so they're ready when you open the page.

Clicking Start Free while browsing the live demo and filling in the signup form showed "This read-only demo can't save changes" and created no account. Signing up, signing in to an existing account, and resetting a password from the demo now end the demo and go through as they would for anyone else.

When an SDK or your pipeline sends something your plan doesn't include (a deploy, performance data, traces, sessions), ForgeOps now answers 202 Accepted with a note that it wasn't recorded and a link to upgrade, instead of 403 Forbidden, so a correct setup never looks broken. The Releases page and an incident's likely cause say when deploys are arriving that your plan doesn't record yet, and what Business would add.

A new organization now starts on a 14-day Business trial, no card needed, so deploy tracking, performance monitoring, and tracing work on your own application from the start, and incidents can show their likely cause and where to look. A banner says how many days are left. When the trial ends, the organization moves to the plan it's paying for: issues and incidents stay, Business-only features stop recording, and anything Business ran on a schedule, like uptime checks, is paused rather than deleted. Each person gets one trial.

Most SDKs send errors from a background thread, and a short-lived program (a script, a cron job, a CLI, `rails runner`) could end before that thread sent them, so they never arrived; that included the Rails test command on a project's setup page. Ruby 0.15.1, Python 0.16.1, Java 0.12.1, Kotlin 0.11.1, Perl 0.12.1, Elixir 0.14.1, and .NET 0.14.1 now send what's still queued when the program exits, waiting at most 5 seconds. Go 0.9.0 and Rust 0.13.0 add a flush call to make before main returns, since neither language runs anything at exit, and now deliver a panic before the program dies. Node 0.16.0, C++ 0.8.0, and Dart 0.13.0 now deliver an uncaught crash before the process ends, and Node no longer stops an unhandled promise rejection from crashing the process. Each language's page says what to call, if anything.

When an organization has more projects than its plan allows, after a trial or a downgrade, the plan's number of projects stay active and the rest are paused. A paused project keeps everything it has, its pages still open, and what its SDK sends is accepted but not recorded. Owners choose which projects stay active on the Projects page (the busiest are kept until they do). Over the member limit, everyone can still look, but only owners can make changes. Upgrading, or getting back under a limit, puts everything back as it was. Changing a project's settings no longer fails while the organization is over its project limit.

Kotlin 0.11.2 now also sends changes recorded with recordChange before a program exits, and .NET 0.14.2 sends TraceAsync traces from a console app the same way, within the same 5 seconds as errors. In both, flush waits for them too.

The privacy policy's list of service providers now includes Anthropic, which powers the optional AI features, with exactly what each feature sends and the fact that nothing is sent until one is turned on. It also says where your data lives: the application, its database, and its encrypted backups are all hosted in New York, United States.

Set your time zone on your account page and every time and date across the app follows it: issue, trace, incident, and audit log times, charts bucketed by day (which now start at your own midnight, not UTC's), and postmortems. Absolute times say which zone they're in ("9:15 AM EDT"), and daylight saving changes are handled for you. Billing periods, quotas, retention, and report schedules still count in UTC, so they're the same for everyone on your team.

An incident's page now opens with its likely cause, right under the summary: what it points at, how confident the match is, and each piece of evidence behind it. When a deploy is the likely cause and your source control is connected, a button opens the pull request that shipped it, alongside who deployed it.

An incident's page is now a numbered path from top to bottom: how many customers are affected and how much the error rate and the endpoint's response time changed, what was deployed or changed just before, the likely cause with a recommended action, the affected endpoint and its slowest captured request, the slowest query in that request, the outside service it was waiting on, and then the full timeline. Each step has one clear next click, and a step with no data behind it is left out rather than shown empty.

Alerts on every channel (Slack, Microsoft Teams, email, PagerDuty, Opsgenie, and webhooks) now say whether something needs attention now, what broke and on which endpoint, how many customers it's affecting, when it started, the deploy that went out just before it with its pull request, and the likely cause with its two strongest pieces of evidence, marked as potentially relevant rather than confirmed. "Investigate in ForgeOps" opens the incident page directly, with buttons for the pull request and the trace where the channel supports them. Email subjects lead with the status, and webhooks keep every field they had, with a new verdict object alongside. Missed heartbeats and down uptime monitors say what's down, since when, and the last error.

An issue's page now opens with what needs attention right now, one fact per line: failures since it started, customers affected, when it started, how the last hour compares with the one before, and the deploy that went out just before it. When the issue is part of an ongoing incident, a link takes you there. Under it, Where to look shows the likely cause and up to four numbered next steps, each with one button: the deployment, the affected request's trace, the slowest database query, and the outside service it waited on. An incident's timeline now also marks when the endpoint slowed down, the first occurrence of the error, when customers affected reached its count, and each alert that was sent, and every entry links to where its detail lives. Both pages also say how many customers failed once and how many repeatedly, and how many times the most affected customer hit it.

A slow request with more than 500 spans, like one running the same query hundreds of times, used to lose its whole trace. Now it keeps its 500 slowest spans, each still nested where it ran, and the waterfall says how many were left out. The queries left out still count on the issue page, so its query total and its N+1 warning describe the whole request. Nothing to update: this works with every SDK version.

Values in captured SQL are now masked in a few more forms: strings with a backslash-escaped quote (o\'brien), strings with a type prefix like X'DEADBEEF' or E'...', hexadecimal, binary, and exponent numbers, and MySQL's double-quoted strings. ForgeOps applies this to everything it receives, whichever SDK version sent it.

Dashboards stack into one column on a phone, and tables keep their key columns on screen instead of cutting them off. A trace folds a run of identical queries into one row ("LineItem Load × 24, 216ms total"), so an N+1 reads at a glance. An incident's page now tells one story: its health reflects the open incident, and when changes were recorded just before it started, the likely cause and recommended action point to them. The on-call calendar matches the dark theme, the audit log reads in plain words ("Incident created") instead of internal names, alert forms show readable triggers and channels, report durations read in days and hours, and a few faint text colors are easier to read.

Searching the audit log for an action as it's shown, like "Incident created", now finds it. Before, only the internal name behind it matched.

A slow request's trace from a Node app now shows every Postgres query run through pg and every Redis command sent through ioredis or node-redis 5.12 and later, with nothing to set up: the SDK picks them up when your app has them installed. Each query carries its SQL with every value masked, and it counts toward the issue page's slowest query and N+1 warning. Python apps get the same for redis-py with one call to init_redis(). Redis spans are named after the command alone, never its keys or values. Needs @forge-ops/tracker 0.14.0 or forge-ops-tracker 0.15.0.

Accepting an invitation with an account you already have now means signing in to it as usual, two-factor code included, and SSO sign-in and SSO connection are tied firmly to the organization that started them. Escalation Acknowledge links now open a confirmation page with a button, work once, and expire after 7 days, so link scanners in email and chat can no longer acknowledge a page for you. Slack and Teams alerts show error titles and other captured text exactly as written, never as links or mentions, and their Resolve and Ignore buttons only act on your own organization's issues. Uptime checks and webhooks only reach public addresses, and report a short reason when a check fails. A ping to a paused heartbeat no longer resumes it, and session replays never load anything from outside the recording.

Signing in through a SAML identity provider now completes instead of stopping with an error on the way back to ForgeOps. SAML sign-in starts from ForgeOps, at your organization's SSO URL, and each response from your identity provider is accepted once, only in the browser that started it, within a few minutes. Sign-ins started from the identity provider's own app dashboard are no longer accepted; point that tile at your SSO URL instead.

Each project can now create an upload token under its settings, for source map uploads and deploy notifications from your CI. Your API key ships inside your app where anyone can read it, so once a project has an upload token those two endpoints only accept the token, and even without one the API key can no longer replace a source map that's already uploaded. Sessions now sign out after 30 days without use and after 90 days at most, you can change your password from your account settings, and changing your password or email or turning two-factor authentication on or off signs out your other devices.

Deploys aren't the only thing that breaks production. Feature flags, config, migrations, dependency upgrades, and infrastructure changes now share one timeline with your deploys on each project's new Changes page, and an issue's verdict lists the ones from the two hours before it started under What changed, labeled potentially relevant. Incident timelines include them too. Record a change with record_change in any of the 20 SDKs or POST /api/v1/changes from CI, and the server SDKs notice runtime and dependency changes (and Rails migrations) on their own at startup; environment variable names are opt in, and their values are never sent.

When an issue's failing request was traced, the issue now opens with its slowest query: how long it took, its share of the request's time, how many queries the request ran, and a likely N+1 warning when the same statement ran five or more times. Every database bar in a trace's waterfall shows its SQL too. The SQL is masked before it leaves your app, every string and number replaced with a question mark, and masked again when it arrives. All 20 SDKs now send SQL on database spans: Rails, Python (Django and SQLAlchemy), PHP (Laravel), and Elixir (Ecto) on the queries they already time, the rest on a database span you create. On PostgreSQL, turn on explain_slow_queries in those four SDKs to capture the plan for a slow SELECT, shown beside the query with any sequential scan over a large table pointed out. It runs plain EXPLAIN, never EXPLAIN ANALYZE, so the query is only planned, never run again.

Every organization now has a Settings section, with single sign-on, SCIM, Slack, Teams, tokens, connected apps, audit log streaming, billing, and deletion in one place, and each project has one Settings page that everyone on the team can open to find its DSN. A new project opens on an install step with its DSN already filled in, and a new organization's overview leads with its setup checklist. Detected problems are now simply Incidents, and what you post for your public status page is Status updates. Buttons you can't use for your role are gone, features your plan doesn't include say so before you click, and a downgrade no longer stops you editing or deleting what you already had. Also fixed: two alerting pages that could fail to load, acknowledging an incident in the app now stops its escalation, on-call forms keep what you typed and offer a simple schedule picker, and status page subscribe and unsubscribe links ask before acting. Settings sidebars stay on screen and follow the section you're reading, and the live demo stays in the demo: the rest of the site looks as it always does, and Exit demo takes you back.

Long audit log actions no longer push the organization overview wider than a phone screen, and the home and pricing pages no longer scroll sideways on small screens. Every page in the app now has its own browser tab title, naming the project or organization you're looking at, so several open tabs are easy to tell apart. The confirmation box for deleting a project or organization now shows its full instructions instead of cutting them off.

An issue's page now puts resolve, ignore, assign, and merge right in its overview card, shows the discussion before the occurrences, and lists occurrences ten at a time with the newest one's backtrace already open. The issue list's filters now fit on one row, so the issues themselves start higher up the page. On phones, the footer no longer stays pinned over the bottom of the screen. And the docs sidebar now highlights the section you're reading and has a box for filtering topics.

Cards across the app now share one heading style, so pages like Performance, detected incidents, heartbeats, and reports read the same way as the organization overview. The pricing and billing pages now say plainly that each project gets its own monthly event quota. An issue's timeline shows the date for anything older than today, not just the time. And the confirmation forms in your account's danger zone stack neatly on a phone.

Heartbeat check-ins, uptime checks, and an issue's resolved or regressed time now read like "Sep 19, 2026 at 8:48 PM UTC" instead of a raw server timestamp. Error titles at the top of an issue or incident now show code quotes exactly as your app raised them, like 'email', rather than as curly quotes.

Every issue now opens with a verdict: Needs attention now, Investigate, Monitoring, or Resolved, shown with the facts behind it: customers affected, which way it's moved in the last hour, when it started, and how long after a deploy. Buttons go straight to the incident, the deploy's pull request, and the traces from around that time. Slack alerts carry the same verdict and buttons, so you can make the first call right from the channel.

Link the projects that call each other, like a mobile app and its API, from a project's settings. An issue then shows the errors a linked project raised in the very same request, and flags ones that only happened at the same moment as possibly related, without ever merging them. With forge_ops_tracker 0.12.0, Ruby errors now name the endpoint they happened on (the issue's verdict shows which endpoint and how much of the issue it accounts for), each occurrence links to the exact trace of its request, a failing request's trace is always kept, and traces follow a request across services using the standard traceparent header. Issues and Slack alerts also link to a comparison with the previous deploy.

With GitHub or GitLab connected, a deploy now says what shipped since the one before it: how many commits and which files changed, right beside the issue or incident that started after it. When your SDK reports request counts, the affected endpoint also shows the share of its requests the issue failed in the last hour. And a detected incident's page, and the on-call pages sent for it by email, Slack, Teams, or webhook, now open with the same Needs attention now, Investigate, or Monitoring verdict.

The Swift (0.4.0), Android and Kotlin (0.8.0), and React Native (0.10.0) SDKs now send the standard traceparent header on requests made inside a trace, and put the trace's id on errors reported with it. With your backend on the Ruby SDK 0.12.0 and the two projects linked, a failed checkout in your app shows the API error from that same request, and one trace follows it from the tap to the database.

Two new feature pages, Triage verdict and Linked projects, walk through today's additions with real screenshots, and the Ruby, Swift, Kotlin, Android, and React Native language pages each show the code to follow a request from your app into your API. The Live Demo now keeps its checkout incident current, so at any hour it opens on a failure that needs attention: the deploy it followed, the endpoint it's hitting, and the mobile errors it caused.

Trace context is in all 20 SDKs. The Python (0.12.0), Node.js (0.11.0), PHP (0.4.0), Perl (0.9.0), Elixir (0.11.0), Java (0.9.0), .NET (0.11.0), and Go (0.5.0) SDKs now put the endpoint and trace id on every error from a request, always keep a failed request's trace, pick up an incoming traceparent header, and pass it on to the services they call. The browser (0.9.0), Objective-C (0.4.0), Dart and Flutter (0.9.0), Unity (0.9.0), Rust (0.10.0), C and C++ (0.4.0) SDKs send it on requests made through a trace and link the errors reported with it. Link the projects that talk to each other, and an issue shows the errors on the other side of the very same request.

When an error comes from a database call, an issue's occurrence now has a Database section naming the stored procedure or function and the tables or views the failing SQL touched, so you know where to start looking. Every SDK supports it: Ruby, Python, Node.js, Java, Kotlin, PHP, .NET, Elixir, Perl, Android, Swift and Dart read the SQL off the error where their database libraries expose it, and Go, Rust, C, C++, Objective-C, Unity and React Native take the statement in one call. The names are sent by default. The SQL statement itself is opt-in, with every string and number replaced by a question mark so no values leave your app. A new project setting, Capture the SQL behind database errors, lets an admin stop the statement being stored at all; the object names are still kept.

Database errors often carry values in their own message: Postgres echoes the start of the failing query and the row that broke a unique constraint, MySQL quotes a duplicate entry, SQLAlchemy lists its bound parameters, and Laravel builds the values into the SQL it appends. ForgeOps now replaces those with a question mark before the message is stored, so a name or an amount in a failing query no longer lands in an issue's title or message. Ordinary messages, including ones with an id in them, are left alone.

Every code block on the per-language pages, install snippets included, now has a copy button in its corner. The lower sections (release health, performance, tracing, custom metrics, database errors and more) now alternate sides like the rest of the page, and each one shows a screenshot of the feature next to its code, on the side opposite the text.

The Free plan now includes 10,000 events a month per project, up from 500, and keeps your events for 14 days instead of 7. When a project reaches 80% of its monthly quota, and again at 100%, the organization's owners get an email that names the issues using the most of it. And a single looping error can no longer use up the month: once one issue repeats faster than its plan's hourly limit (50 an hour on Free), further repeats are counted but not stored or charged to your quota. They still add to the issue's occurrence count and to spike alerts, and new issues and regressions are always stored in full.

A project's settings page now shows its full DSN, with a copy button, so you can paste it straight into your client's config instead of assembling it from the ingestion URL and API key. Those two values are still listed underneath.

Renaming or removing a job class breaks every job still queued under the old name, often hours after the deploy, and no test can catch it because those jobs live in Redis, not your repo. When a Sidekiq job fails because its class no longer exists, the issue now says so, names the class, and shows how soon after which release it first appeared. Your new-issue alerts carry the same explanation. Plain Sidekiq jobs are covered as they are; ActiveJob jobs need forge_ops_tracker 0.10.1 or later, which also reports the real error behind any failing Sidekiq job instead of a generic wrapper.

The Performance page has shown percentile latency for Ruby apps for a while. Python, Node.js, PHP, Java, Kotlin, .NET, Go, Perl, Elixir, Rust, browser TypeScript, React Native, Dart and Flutter, Android, Swift, Objective-C, and C++ now send the same latency histogram, so a transaction's p50, p95, and p99 show up on the request panels whichever of those languages your project is written in, instead of only an average. Percentiles are accurate to the width of the latency bucket a request falls into. You need at least these versions: Python 0.10.0, Node.js 0.9.0, PHP 0.2.0, Java 0.7.0, Kotlin 0.6.0, .NET 0.9.0, Perl 0.7.0, Elixir 0.9.0, Rust 0.8.0, browser TypeScript 0.7.0, React Native 0.8.0, Dart 0.7.0 and Android 0.6.0. Go, Swift, Objective-C and C++ send it from their current releases.

Hiding the setup checklist on an organization's overview page used to be permanent. Admins can now bring it back with a Show setup checklist button beside Status page and Edit while it is hidden, and from the organization's Edit page, which also works once every item is done and the checklist has hidden itself.

Each dashboard widget's pair of buttons is now a quiet Edit / Remove link, matching the notification rules and members tables. On every one of those tables, Edit now turns yellow on hover instead of green, so a row reads green, yellow, red: a safe action, Edit, then Remove.

Once an incident was fixed it dropped off the overview entirely, so there was no quick way back to what had just been resolved. The overview now lists the five most recently resolved incidents from the past month under What's broken, each linking to its own incident page with the signals and probable cause.

Moving the pointer over the Live Demo link on the marketing pages could quietly open the demo in the background and sign you into it, so the next page you clicked showed the demo's navigation instead of the site's. The link now waits for a real click.

The language pages for TypeScript, React Native, Kotlin, Android, Swift, Objective-C, C++, Rust, Dart and Unity now have a Performance monitoring section with the exact call to make, what is and isn't timed automatically, and when to flush. The organization overview section of the docs also describes the three questions it answers, the recently resolved list, and the setup checklist, and the dashboard and overview screenshots were refreshed.

The Dart / Flutter page now has a Flutter apps section: the two-package install, the one call that covers a widget-build error and an uncaught async error, and what to flush when the app is paused. flutter_forge_ops_tracker 0.2.1 also now accepts any current forge_ops_tracker release, so it no longer falls behind at the next version, and the install lines use pub add, which always installs the latest.

The Unity package had no public download, so its install step pointed at a folder only we could reach. It now lives in its own public repository, and the Unity page shows the one line to add to your project's Packages/manifest.json, or the same URL in the Package Manager's Add package from git URL. It has been compiled and tested against a stand-in for the Unity API but not yet run inside a real Unity Editor, so try it in a scratch project first.

Every language page, the docs and the SDK READMEs showed the connection string with a made-up host, your-forgeops-host, as if you ran ForgeOps yourself. They now show getforgeops.net, so the example is the exact string to use once you swap in your project's API key.

Several language pages and the docs gave install steps that didn't work or fetched a very old release: Java, Kotlin and Android pointed at folders only we could reach, and Dart, Rust and Elixir pinned versions from months ago, so following them installed the oldest release instead of the latest. They now show the real Maven Central, pub.dev, crates.io and Hex coordinates, and .NET shows its NuGet command. Go, Swift, C, C++, Objective-C and PHP install from tagged releases, and their newest tags were months old, so a default install got outdated code. Each now has a current release tag (Go v0.3.0, PHP, Swift, C, C++ and Objective-C v0.2.0). The Flutter package, which had the same stale Dart dependency, is now flutter_forge_ops_tracker 0.2.0.

These were Ruby-first, with tracing also in Python and Node. They now ship across the rest of the SDKs too, including Go, Java, Kotlin, .NET, PHP, Elixir, Perl, Rust, C, C++, Objective-C, Swift, Android, Unity, Dart, React Native, and browser TypeScript. Send a named business metric or a server reading with one call, and see a slow request's full span waterfall, whichever language your project is written in.

The in-app docs have new sections for performance monitoring, distributed tracing, custom metrics, and infrastructure monitoring, each with the exact call to make, and a new Features page covers custom metrics and infrastructure readings. The demo screenshots across the site were refreshed to match the current app.

An organization now starts with two dashboards instead of one: an Executive overview built from top-line, business-outcome widgets, and an Engineering overview for the more granular, per-exception-class detail that used to be mixed into the same view.

A detected incident now shows other projects affected by the same release, real occurrence and related-issue counts, and, when a real escalation actually fired, who's on call, plus links straight to the specific release and to the traces captured during the incident's own window.

Each project's own card now shows its unresolved issue count with a severity indicator, how many issues have ever regressed, and, for a project with an uptime monitor, a blended uptime percentage, instead of just its name and language.

New issues, downtime, resolved issues, and MTTR (mean time to resolve) each now show how they compare to the immediately preceding period of the same length, colored by whichever direction is actually an improvement for that specific metric.

Each of the five Core Web Vitals cards now shows a small sparkline of that metric's own daily p75 over the trailing week, right under the current number, so you can tell at a glance whether it's getting better or worse, not just what it is right now.

The homepage now leads with "Explore the Demo" as one of its two primary actions, the Features page links straight to the live demo at both its top and bottom, and the demo itself now shows a banner linking back to every feature, so it's no longer a dead end in either direction.

"Live Demo" is now a top-level link in the main navigation, right next to Features, and the pricing page's own closing call to action now offers it alongside "Get started free", so it's reachable from wherever a visitor happens to land, not just the homepage.

A project with a lot of distinct transactions, queries, jobs, or external services used to make its own table grow tall enough to push everything below it out of view, with no visible sign it was even scrollable. Every table on the Performance page now caps its own height and scrolls internally instead.

Changing an issue's status or assignee right from the issues list used to send you back to the very top of the page every single time, since it was a full page reload under the hood. It now updates that one row in place instead, so triaging a whole list one issue after another no longer means scrolling back down to find your place.

Request performance, Database, Background jobs, and External services used to sit two to a row, which was cramped enough to wrap a lot of real transaction and query names onto two lines. Each one now gets the page's full width instead, stacked one under the other.

"Set up alerts" and "Connect deployments" on the "Finish setting up ForgeOps" checklist used to send you to the plain project list either way, leaving you to find the right settings yourself from there. With exactly one project, both now jump straight to that project's own notification rules or source control settings instead.

A real docs section under Errors & alerting now covers both ways to record a deploy: calling the Deploys API directly from your own CI/CD (a copy-pasteable curl example included), or connecting GitHub or GitLab so a real deployment there records and enriches one automatically. Neither one had ever been written down anywhere before.

Search across every project in an organization at once, backed by real trigram indexes, instead of already needing to know which project an issue lives in before you can find it.

An organization's dashboard now leads with a real needs-attention digest of unresolved issues and open incidents, instead of a generic widget grid that looks the same whether anything is wrong or not.

Connect GitHub or GitLab and a detected incident now links directly to the pull request behind the deploy that likely caused it, instead of leaving you to go find it yourself.

Turn on tracing in the Ruby, Python, or Node SDK and see one real request's full span waterfall end to end, instead of only an aggregate latency number that hides which specific call was actually slow.

Once an incident resolves, ForgeOps writes a first draft postmortem straight from its own detection signals and timeline, instead of leaving the writeup entirely to whoever was on call.

Connect a repository and every deploy shows up with its real release, environment, commit, and who deployed it, so a spike in errors can be lined up against what actually shipped, down to the pull request.

ForgeOps now detects an incident on its own from correlated signals like an error spike or a deploy, builds a timeline of exactly what happened, and runs a deterministic rules engine to suggest a likely cause, instead of leaving someone to notice a spike and piece the story together by hand.

An organization's first project now seeds a starter dashboard chosen for that project's own language, instead of an empty dashboard you have to build from scratch before seeing anything useful.

Every backend SDK now detects the signed-in user automatically (Warden/Devise, Django/Flask, Laravel, Spring Security, and more), or accepts one explicitly through a manual set_user call, so an issue shows real affected users instead of only an event count.

A new email now has to be confirmed before it takes effect, and the account keeps signing in with the old address in the meantime, instead of switching immediately on a possible typo.

Send your own named, numeric metrics from the Ruby SDK and see them next to built-in infrastructure widgets like job queue depth and database connection pool usage, instead of only ever seeing what ForgeOps captures on its own.

Every server SDK, not just Ruby, now times each controller or request automatically and reports it as a performance sample, so p50/p95 latency and slow endpoints show up on the dashboard no matter which language a project is written in.

Passwords now require a minimum of 8 characters, enforced both when you sign up and whenever you set a new one.

Every update on one of your organization's own status page incidents now shows who posted it, and the incidents list shows who actually resolved each one, not just when.

The Downtime incidents figure on both the Reports page and the scheduled report email was only ever counting missed heartbeats. It now includes downtime detected by uptime monitors too, so the number actually matches what it's labeled.

The PII scrubbing page now shows an actual redacted issue, not just a description of the rules: an email address and an api_key field both caught and replaced before storage, sitting right next to an unrelated field that's correctly left untouched.

Code that catches its own error to keep running (a third-party API call, an SFTP upload, a webhook post) never used to reach ForgeOps at all, since nothing ever crashed. Every SDK now exposes a direct capture call for exactly that, right at the catch/rescue/except site, with a context hash that shows up as inspectable JSON on the issue. See it for your own language on the new Handled exceptions page.

Export everything ForgeOps has on your organization as a downloadable archive, or permanently erase your account and its data, right from account settings, instead of needing to email support to do either.