Summer 2027
Posted on 8/11/2026
Developer-first application monitoring and error tracking
$53.13/hr
San Francisco, CA, USA
Hybrid
Relocation to San Francisco is required for the internship; temporary relocation support and housing are provided.
Bachelor's
See people who can refer or advise you
Sentry helps software teams monitor and fix problems in web, mobile, and backend apps. It tracks errors, exceptions, and performance issues and turns them into organized problems that are linked to specific code commits and releases. The platform includes error monitoring, performance tracing, session replay, logging, and AI-assisted debugging tools, and it supports more than 100 languages and frameworks. It was built from an open-source error-logging tool and now offers a developer-focused, self-hostable observability solution that integrates with tools like GitHub, Slack, and Jira. Compared with broader observability suites, Sentry emphasizes a developer-centric workflow and tight integration with code changes, making it easier for engineering teams to diagnose and resolve production issues quickly.
Company Size
201-500
Company Stage
Series E
Total Funding
$216.5M
Headquarters
San Francisco, California
Founded
2011
See people who can refer or advise you
Help us improve and share your feedback! Did you find this helpful?
Competitive Compensation + Equity
401(k) Plan
Medical, Dental, Vision Insurance
Commuter Stipend
Professional Development Stipend
Health & Wellness Benefits
Charitable Matching Program
Flexible PTO
Paid Parental Leave
Sentry's Greg Pstrucha on why a better prompt won't fix your agent's code. Sentry staff engineer Greg Pstrucha on linters, stronger tests, evals for Seer, and the quality metrics agents game - from AI Engineer World's Fair 2026. Noelle Festa August 6, 2026 Explore with AI At the AI Engineer World's Fair in San Francisco, I sat down with Greg Pstrucha, a staff software engineer at Sentry, on the day he gave his talk "Stop Prompting". The title is the whole argument. If the code your agent hands back keeps making the same elementary mistakes, the answer is rarely a better prompt. It's tooling in the coding harness that raises the floor of what the agent can produce in the first place. Sentry is not a place where code goes unread. The team still reads a lot of code, because breaking production for customers is expensive, and they aren't doing full-on loop engineering. What Greg is optimizing is the part in between: the repetitive feedback engineers give agents over and over, which he thinks can largely be swept away by deterministic rules, things like linters, good tests, a proper type system, and skills that steer the agent. Sentry's own description of the talk frames it as tooling, type systems, and frameworks enforcing limits on the slop AI agents produce inside large codebases. The cheapest version of that is embarrassingly cheap: "You can spend half an hour today and you're going to significantly improve the output by just adding good linters." The policies a linter can't hold. Deterministic rules get you the floor. Above the floor sit the judgments Greg calls the policies of your codebase, the things that resist codification: "there are these qualitative measures that are going to be hard to codify in any reasonable way. And those are what I would call like policies of your code base, things such as you shouldn't write too many tests, but you should write stronger tests." Stronger has a specific meaning here. A stronger test is one that doesn't try to test behavior that isn't actually important. His example comes from writing evals, where the temptation is to assert on strings: "I would rather have good tests that use LLM as judge to say whether the output of the agent is correct as opposed to match like assert whether a string had a substring in it because that can be extremely misleading to the actual output that are more semantic." Asked how to split deterministic tests from evals, he said he doesn't have a clean answer, and that you want both: a good set of tests as the baseline, with evals reserved for the agentic code and LLM chats where plain assertions stop working. An eval that stops at the root cause is only half an eval. Greg works on Seer, Sentry's debugging agent, which uses issue details, tracing data, logs, and profiles to troubleshoot errors and performance problems. Seer is mostly tested through evals, an extensive harness of input and output combinations checked against the expected outcome. The interesting part is where the expected outcome sits. Seer's Autofix scans issues as they arrive, finds root causes, and can generate a fix and open a PR, on GitHub or as a merge request on GitLab. So the eval can't stop at the analysis. What Sentry checks is whether the agent gets the root cause right, then whether it produced the correct PR artifact, in the correct source control system, at a high enough code quality bar. Evaluating an agent that writes code takes the same apparatus you would use to review your own code. The linters and tests are the grading rubric, not a developer nicety sitting outside the agent loop. All agents are coding agents. Seer writes code twice over. It writes code as its output, and it writes code it runs itself to pull context and telemetry out of Sentry's public APIs, a mechanism the team calls code mode. Those throwaway snippets are held to the same standard as anything else: "That code itself, that snippet of code must be correct, must be linted, must match the API schema that Sentry presents." Which is where his framing lands: "This is what we say is that all agents are coding agents." It follows a thesis a lot of companies now share: agents do better when they are writing code or working against developer interfaces and APIs. If that holds, the tooling investment doesn't split between "our coding agent" and "our product agent." It's one investment. The metrics that didn't survive contact. I asked what he had tried that didn't work, because that's usually the more useful half of the story. He gave two, both from the same family: "There is a little bit of a snake oil when you try to put a quantitative metric on something that's inherently qualitative." The first was cyclomatic complexity, a metric that estimates how maintainable and testable code is from how many branches it takes and how deep the call stack goes. The second was test coverage: "Using test coverage as a number that says how well the code is tested, which in my experience doesn't really tell you how well the code is tested, just how many tests you have." This is Goodhart's law with a much faster optimizer attached: "They give a numerical target for the agents that then the agent can just drive down or up depending on the metric." A proxy metric doesn't capture the thing you wanted it to capture, and Greg is blunt about the alternative: "I don't know how to make a good measure of quality other than use engineering minds for that." That's an ugly answer if you were hoping to buy your way to an autonomy dashboard, and it's the one that matches how his team actually works. What would have to be true to stop reading the code. Since Sentry still reviews code by hand, I asked what would have to change for that to stop. His answer treats review as a spectrum rather than a policy: on side projects he barely reviews, because the stakes are low; at Sentry he reviews more, especially on the critical path, where a mistake hurts. Sentry already runs automated reviewers, Cursor's Bugbot plus their own code review tool, and Greg runs a review locally before opening a PR. The signal he's waiting on is empirical: "if those stop giving me actionable feedback and if my code review that I internally run locally before creating a PR stops giving me feedback and I keep reading the code and I'm like that's good. Then I'm going to be more comfortable with not reading the code." He wants the endpoint: "I think there is a future hopefully where you just don't have to have code reviews. It just goes straight to main, straight to main. And I know some people already live that future. I just don't see it yet." What he's watching for is a new generation of coding harnesses that treat measuring quality as a first-class part of the framework, rather than something each team bolts on afterward. He knows of a few, and he's waiting to see whether any of them can prove to him that he no longer has to read the code. The gap is infrastructure, not intelligence. Internally, Sentry's tooling is unglamorous: vanilla Claude Code and Codex, with some engineers on OpenCode through API access. They experimented with cloud coding agents like Devin, and Greg's verdict was that it was fine but not there yet for his workflow: "you're working on a mature code base. Multiple services. You have to like really really create your workspace to work. And doing that sort of on a whim in sandboxes just didn't really work yet for me." He's careful about where he assigns the blame: this is a tooling and infrastructure problem rather than a model problem, and he expects it to be solvable. For Sentry, the capability showed up before the plumbing that would let a mature, multi-service codebase use it. Which is why the half hour of linters is the right first move. Everything else here, the harness, the eval framework, the cloud sandboxes, is still being worked out in public on a timeline nobody can call: "if you look at what we've been doing a year ago with agents, it was like it's so different. I can't even guess what we're going to be doing 1 year from [now]. All these predictions don't even matter cuz things change so much and so fast." Half an hour, good linters, today. That part doesn't depend on which harness wins.
.NET support for Godot is now generally available. Sentry Inc. recently released version 2.0.0 of Sentry's Godot Engine SDK, bringing C#/.NET support and application metrics to general availability. That means you can now capture errors from your managed C# code and track custom metrics across your development and retail builds. C#/.NET support. Godot supports two fairly distinct worlds of scripting: GDScript and C#. During the 1.x releases, Sentry Inc. instrumented the SDK to capture issues from GDScript, the engine itself, and the native C/C++ code, and expanded support to all officially supported platforms. With the 2.0.0 release, Sentry Inc. is introducing first-class error reporting for .NET in Godot Engine. Errors from your managed code now appear on the same trace alongside GDScript and engine issues, and scope elements like tags, breadcrumbs, and user context are present where they're currently synchronized. So, let's see how this works in practice. Here's a short version of C# code that throws at runtime in its Godot game: private List<UpgradePathBase>? TryFetchUpgradesFromServer {var fetchTransaction = SentrySdk.StartTransaction("fetch_upgrades", "http.client"); return ParseUpgradeData(FetchUpgradeDataFromServer(fetchTransaction), fetchTransaction);} private List<UpgradePathBase>? ParseUpgradeData(string responseContent, ITransactionTracer transaction) {//... // Parsing the server response throws JsonException var serverResponse = JsonSerializer.Deserialize<ServerUpgradeResponse>(responseContent); var upgradePaths = new List<UpgradePathBase>(serverResponse!.upgrades.Length); //...} The SDK captures the error at runtime and sends an envelope to your Sentry project. This is how the issue looks in Sentry: Sentry has integrations for most popular SCMs, like GitHub, and can fetch the source code context around each frame right from your repository. Metrics. To better understand performance across different hardware configurations, you can send metrics to Sentry so you can track performance over time and slice it by custom attributes. In this example, Sentry Inc. measure the actual time between frames instead of relying on the engine's delta time, since delta time is typically clamped and smoothed. Sentry Inc. also attach CPU and GPU attributes, making it easy to slice the data by hardware configuration. You can add other attributes to narrow the data down even further, such as the game level where the metric was recorded. Here Sentry Inc. is looking at the p95 frame time to spot configurations where the game consistently struggles to run smoothly. This makes it easier to identify hardware-specific performance issues, or even level-specific bottlenecks, and focus your optimization efforts where they'll have the biggest impact. extends Node ## Samples frame time and sends it to Sentry as metrics. const FRAME_SAMPLE_INTERVAL_MS := 100.0 var _time_since_sample: float = 0.0 var _last_frame_usec: int = Time.get_ticks_usec func _process(_delta: float) -> void: var now := Time.get_ticks_usec var frame_ms := (now - _last_frame_usec) / 1000.0 _last_frame_usec = now _time_since_sample += frame_ms # Sample at a fixed interval to avoid producing too many metrics. if _time_since_sample >= FRAME_SAMPLE_INTERVAL_MS: _time_since_sample = 0.0 var attributes := {"gpu.name": RenderingServer.get_video_adapter_name, "cpu.name": OS.get_processor_name, "cpu.cores": OS.get_processor_count,} SentrySDK.metrics.distribution("perf.frame_time", frame_ms, SentryUnit.millisecond, attributes) For another example, let's track how long runs take and what experience level players reach on average in a roguelite/survivors-style game. game.run.time records the total time it took to complete a single run, while game.run.xp_level records the experience level reached during that run. This example shows that metrics can be used to track more than just performance: they're also useful for gameplay events. Data like this can help you balance gameplay variables and create a better experience for your players. extends Node ## Sends gameplay metrics to Sentry by listening for game events ## on the EventBus. func _ready -> void: EventBus.connect("EnemyDestroyed", _on_enemy_destroyed) EventBus.connect("RunEnded", _on_run_ended) func _on_enemy_destroyed(_score_value: int) -> void: SentrySDK.metrics.count("game.enemies_killed", 1) func _on_run_ended(xp_level: int, time: float) -> void: SentrySDK.metrics.distribution("game.run.xp_level", xp_level) SentrySDK.metrics.distribution("game.run.time", time, SentryUnit.second) Try it out. Give it a try! Sentry Inc. want to hear your feedback as Sentry Inc. continue to improve the SDK. To get started, download Sentry from the Godot Asset Store, or directly from GitHub. Extract the archive into your project, set your DSN in the project settings under Sentry > Options, and let the errors come through with full context. For more details, check out the dedicated C#/.NET guide. Happy debugging!
New IncidentRelay platform brings open-source on-call management. IncidentRelay is a new self-hosted platform for on-call scheduling, alert routing, escalations, and incident response. IncidentRelay, a new open-source platform for managing on-call schedules, alert routing, escalations, and incident response, has reached its first stable release, version 1.1, following several beta builds. The project targets SRE, DevOps, platform, infrastructure, and operations teams seeking to manage incident workflows on their own infrastructure rather than relying exclusively on hosted services such as PagerDuty. To be clear, IncidentRelay is not another monitoring system. Instead, it sits between existing monitoring tools and the people responsible for responding to their alerts. When a monitoring platform detects an issue, IncidentRelay receives the alert, verifies its source, labels, severity, routing rules, and team ownership, then forwards it to the appropriate on-call responder. The alert can then be acknowledged, resolved, silenced, or escalated if there is no response. IncidentRelay supports on-call schedules, recurring rotations, temporary overrides, reminders, and escalation chains. Unacknowledged alerts trigger repeated reminders before escalating to the next person in the rotation, helping teams avoid missed critical alerts. The platform also provides maintenance windows and alert silences for planned work, along with grouping and access controls for organizations running several infrastructure or development teams. Plus, its calendar interface shows current assignments and overrides. For incoming alerts, IncidentRelay integrates with Prometheus Alertmanager, Grafana Alerting, AWS SNS and CloudWatch, Zabbix, Sentry, LibreNMS, RMON, and generic webhooks. Notifications are delivered via Slack, Mattermost, Telegram, Discord, Microsoft Teams, email, outbound webhooks, browser or PWA push notifications, and pluggable voice-call providers. The platform features group-based access controls and multi-team support, as each route uses a unique intake token, allowing administrators to specify which external systems can submit alerts to a team or rotation. The application also exposes documented OpenAPI endpoints and supports personal API tokens. In addition, a separate Terraform provider is available for teams that want to manage parts of their IncidentRelay configuration through infrastructure-as-code workflows. Expectably, as a self-hosted platform, IncidentRelay operates with an organization's own database, network rules, and operational policies. Administrators can choose between SQLite support for smaller, single-node deployments and PostgreSQL, which is recommended for larger or long-term installations. Deployment options include Docker Compose, a Helm chart for Kubernetes, and manual systemd installation. An RPM repository is available for RHEL-compatible distributions. IncidentRelay is written primarily in Python and distributed under the permissive MIT license. Tell others: Bobby borisov. Bobby, an editor-in-chief at Linuxiac, is a Linux professional with over 20 years of experience. With a strong focus on Linux and open-source software, he has worked as a Senior Linux System Administrator, Software Developer, and DevOps Engineer for small and large multinational companies.
Laravel application monitoring & debugging with Sentry. At Laravel, Laravel LLC. equip PHP developers with the most advanced tools to create exceptional applications. Today, Laravel LLC. announce its partnership with Sentry, making it a preferred monitoring and debugging solution for Laravel projects using Forge or Vapor. This collaboration marks a significant step forward in its mission to ensure that PHP developers have access to modern, powerful tools to streamline app development. Why Sentry? When it comes to application monitoring, having a centralized platform to understand how errors and performance issues impact your application is crucial for fixing the broken code quickly. Sentry stands out as a world-leading debugging platform, trusted by Fortune 500 companies worldwide. It offers developers real time code visibility and debugging capabilities, helping developers identify and resolve issues swiftly. By integrating Sentry with Laravel's services, Laravel LLC. is providing PHP developers with a robust solution to maintain high-quality, error-free, and performant applications. Sentry already serves thousands of Laravel applications and Laravel LLC. is thrilled with their increased commitment to improving workflows for PHP developers. Who should use Sentry? Whether you're a solo developer, part of a small team, or working on enterprise-level projects, Sentry helps you identify the root cause of an issue, down to the broken line of code. Its scalability and flexibility make it an ideal choice for anyone building web applications with Laravel. Sentry ensures that you have a comprehensive view of errors and slowdowns affecting your app, enabling you to maintain a seamless user experience and robust application performance. Benefits for PHP developers. If you're working on an existing PHP project, you may already have Sentry installed. If you don't or if you're just getting started on a new endeavor, awesome - you can sign up for and add Sentry to your page/site from Forge or Vapor. The integration will automatically notify Sentry that you created a new page/site and will create an associated Sentry project for you. This is just the beginning of what Laravel LLC. is able to do to make sure PHP developers get the right telemetry they need even before they push to production. Integration with Laravel Forge and Vapor. Laravel LLC. is excited to announce that integrating Sentry with Laravel Forge and Vapor is now easier than ever. Laravel Forge and Vapor are already simplifying the process of deploying and managing PHP applications. With its new integration, activating Sentry within these environments is a breeze. Here's how you can do it: * Log in to Laravel Forge or Vapor * Navigate to "User Profile" in Forge or "Team Settings" in Vapor (when logged in as the team owner) where you can find the new Sentry integration option. * Follow the prompts to link your Sentry account * Configure Sentry and connect your site to create a Sentry project create the project from the site's or project's Sentry panel * Deploy your application, and Sentry will start tracking errors immediately Visual demonstration. In the past, integrating Sentry required multiple steps and configurations. Now, almost everything is handled directly within Forge and Vapor, simplifying your workflow significantly. Documentation and support. Comprehensive documentation (Forge / Vapor) is available to guide you through setting up and configuring Sentry with your Laravel applications. Laravel LLC. is committed to providing the resources and support you need to make the most of this powerful tool. Please try & tell Laravel LLC. what's next. The partnership between Laravel and Sentry is just the start of a new era in PHP development driven by the Laravel Community - please tell Laravel LLC. how you like this integration and what services to focus on next. By combining Forge and Vapor with Sentry's leading application monitoring platform, Laravel LLC. is empowering developers to build better, more reliable applications. Laravel LLC. invite you to explore this new integration and see how it can enhance your development workflow. Explore the new Sentry integration with Laravel Forge and Vapor today. Laravel LLC. look forward to your feedback and suggestions as Laravel LLC. continue to improve and innovate. Together, let's take PHP development to new heights! A recap of the first Laravel Live Japan: two days in Tokyo, 550+ attendees from 40 countries, live AI translation, and a community that proved PHP has no borders. Ryuta Hamasaki Dave Hicking Discover Laravel events, meet your people, and level up as a developer. Download the Laravel Community app on iOS and Android.
Harness acquires Codecov from Sentry to strengthen Software Delivery governance in the AI era. Read the article at: Integration embeds code coverage intelligence directly into the delivery pipeline, strengthening governance across the software delivery lifecycle SAN FRANCISCO, June 2, 2026 - Harness, the AI Software Delivery Platform(TM) company, and Sentry, the leader in application monitoring, today announced that Harness has acquired Codecov from Sentry. AI is helping engineering teams create and deliver software faster than ever, but speed without visibility can introduce new quality and release risk. By embedding Codecov's coverage intelligence into Harness, teams can move quickly while maintaining the governance needed to understand what was tested, where risk exists, and what is safe to ship. For years, software delivery moved at human speed, with changes written, reviewed, and tested by people. AI has removed that constraint - teams now produce more code than ever, increasingly with agents generating changes alongside humans. The systems responsible for testing, validating, and governing software haven't kept pace, leaving teams with less visibility and control over what they are actually releasing. Codecov provides critical visibility into how much of an application's codebase has been tested and whether it meets the threshold required to ship safely. By embedding Codecov's coverage intelligence directly into the Harness delivery pipeline, coverage signals can inform real-time release decisions before code is shipped to production. "AI is dramatically accelerating code creation, but software delivery ultimately comes down to deciding what's safe to release and when," said Jyoti Bansal, co-founder and CEO of Harness. "By bringing Codecov into Harness, we can connect coverage data directly to delivery decisions so teams can move faster without sacrificing trust in what they ship. The future of software delivery will depend on turning signals like coverage into enforceable decisions that guide every release." With Codecov joining Harness, coverage data becomes part of the Harness Software Delivery Knowledge Graph, which connects deployment signals across the delivery lifecycle. Codecov adds a critical new layer to that intelligence: real-time coverage data tied directly to the repositories and changes flowing through the delivery pipeline. By connecting coverage data with deployment history, security reachability analysis, incident telemetry, and change history, the platform can help teams understand release risk before code reaches production - giving them visibility into what changed, what was tested, and where risk may be accumulating as software delivery continues to accelerate. Commitment to the Codecov product and community. Codecov is trusted by thousands of development teams and widely used across the open source ecosystem. Harness plans to continue investing in Codecov while preserving the experience teams rely on today. The transition reflects a shared view that modern software delivery depends on strong alignment between development signals, operational visibility, and release governance. Harness plans to accelerate innovation in Codecov while retaining its brand and free access for open source projects. "Sentry's mission is to help developers see what's breaking in production so they can fix it fast. This focus is what shapes every decision we make," said Milin Desai, CEO, Sentry. "Codecov has become an important tool for thousands of engineering teams, and it deserves the investment and roadmap focus to match that. Coverage intelligence works best when it's embedded in the delivery pipeline, and that's exactly where Harness operates. We didn't just find Codecov a home, we found it the right one." Ongoing partnership between Harness and Sentry. Harness and Sentry are committed to ensuring continuity for Codecov users while building long-term momentum for the product. The companies share a belief that the future of software delivery requires closer alignment between quality, reliability, and visibility. Together, Harness and Sentry will continue supporting developers and engineering teams through integrations, developer community engagement, and shared efforts to advance the tools and practices needed for the AI-accelerated future of software delivery. About Harness. Harness is the AI Software Delivery Platform(TM) company, enabling engineering teams to build, test, and deliver software faster and more securely. Powered by Harness AI and the Software Delivery Knowledge Graph, the platform brings intelligent automation to every stage of the software delivery lifecycle after code - removing toil and freeing developers from manual, repetitive work. Companies like United Airlines, Morningstar, and Choice Hotels use Harness to accelerate releases by up to 75%, cut cloud costs by 60%, and achieve 10x efficiency across DevOps. Based in San Francisco, Harness is backed by Goldman Sachs, Menlo Ventures, IVP, Unusual Ventures, and Citi Ventures. About Sentry. Sentry helps every developer detect, understand, and fix broken code, fast. Using Sentry's debugging platform decreases resolution time from days to minutes, giving developers more time to do the stuff they love, all while making customers happier. Sentry is used by over 4 million developers and 150,000 organizations, including Disney+, Cloudflare, GitHub, Anthropic, Vercel, and Atlassian. GitOps, Security, and Modern CI/CD Pipelines Tackle the Tedium: Automation for Better Business Shadow IT Isn't Your Enemy - It's Your Secret Weapon Harness Named to Fortune's 2026 America's Most Innovative Companies List 3 Security Investments Takeaways From RSA 2023