Evidence without production control
Context reads operational signals from connected systems without permission to change production.
Context / Operational context in Slack
Operational context for engineers, directly in Slack.
Slack-native /context check
Context helps engineering teams understand production issues faster by turning read-only evidence from AWS, GitHub, deploys, logs, alerts, and Slack into a sourced briefing.
- Recent deploys, AWS changes, logs, alerts, and Slack context in one place.
- Source links for every finding, so engineers can verify before acting.
- Useful for incidents, on-call, deploy debugging, support escalations, and handoffs.
Production context is scattered.
Alerts rarely explain what changed. The evidence engineers need is spread across AWS, GitHub, dashboards, logs, deploy history, Slack threads, runbooks, and previous incidents.
- What changed?
- Why did this alert fire?
- Was there a deploy?
- Did AWS change?
- Where are the logs?
- What has already been checked?
- Who owns this?
A context layer above your tools.
Context does not replace the systems your team already trusts. It pulls the relevant evidence together, summarizes it in Slack, and keeps the original sources one click away.
Slack-native operational workflow
Investigations start where engineering coordination is already happening: the team channel.
Source-linked production context
Every useful finding points back to the system of record, so engineers can check the evidence.
For everyday production questions.
Incidents are one entry point. The broader value is day-to-day operational context for on-call, deploy debugging, status updates, handoffs, support escalations, and service lookup.
Initial wedge
Incident investigation
checkout-api starts returning 5xx errors
Responders see the recent changes, unhealthy signals, and strongest next investigation path.
The page comes with context
A paged engineer can see why the alert fired, what changed nearby, and whether the signal looks actionable.
Deploys connected to symptoms
Recent PRs, commits, releases, and AWS changes sit next to the production signal.
A clear change window
Code, deploy, and AWS changes are grouped around the service and time range.
Cleaner channel updates
The team gets a current-state summary without asking responders to repeat themselves.
Better shift transitions
Known facts, checked items, open questions, and next steps move with the work.
Service context on demand
Owners, repos, dashboards, alarms, AWS resources, deploy history, and runbooks become easier to find.
Ask from Slack.
A small command set turns production questions into sourced answers without adding another dashboard to maintain.
Pattern
/context <action> [service] [window]
/context check
Production issue context
Recent changes, unhealthy signals, relevant logs, and practical next checks for a service, alert, or production problem.
/context check checkout-apiA useful first briefing.
When production gets noisy, Context gives the channel a grounded starting point: what changed, what looks unhealthy, and which evidence deserves attention first.
/context check checkout-api
Check - checkout-api
Status
Degraded. checkout-api is returning elevated 5xx errors in production. The increase began around 14:07 UTC and appears focused on the checkout payment flow.
Summary
Context found a related deploy, degraded ALB target health, an active CloudWatch alarm, and increased timeout errors in the same investigation window.
What changed
- PR #1842 merged 18 minutes before the error spike.
- Commit 9f31c8a was deployed to production at 13:52 UTC.
- CloudTrail shows an ECS service update for checkout-api-prod at 13:54 UTC.
Unhealthy signals
- CloudWatch alarm checkout-api-5xx-rate-high is active.
- ALB target group checkout-api-prod-tg has 2 unhealthy targets.
- Logs show increased PaymentProviderTimeoutError.
Suggested next checks
- Compare error rate before and after deploy 9f31c8a.
- Review timeout and retry changes in PR #1842.
- Inspect logs from the two unhealthy ECS tasks.
- Confirm rollback availability for the last production deploy.
Source links
CloudWatch
ECS
ALB
GitHub
CloudTrail
Logs
Actions
How Context works
Context connects the places production evidence already lives, then returns a sourced briefing in Slack.
-
01
Slack, AWS, and GitHub connected
Setup starts with the tools most small production teams already depend on.
A scoped read-only AWS role keeps the first integration narrow and auditable.
-
02
Questions start in Slack
Engineers can request context for a service, alert, deploy, or handoff with /context check checkout-api, /context changes checkout-api, /context status, or /context handoff.
Engineers stay in the workflow where coordination is already happening.
-
03
Read-only evidence collection
Context looks across GitHub PRs, commits, releases, deploys, GitHub Actions runs, CloudTrail events, CloudWatch alarms, logs, ECS, Lambda, ALB, RDS, and relevant Slack messages.
No production changes, no auto-remediation, no telemetry ingestion by default.
-
04
A sourced answer returns to the channel
The briefing includes status, recent changes, unhealthy signals, suggested next checks, handoff notes, limitations, and source links.
Engineers verify before acting.
Production context that helps.
Focused capabilities for teams that need better answers without building an internal SRE platform.
Starts in Slack.
No dashboard detour before the first useful answer.
Small command surface
Memorable actions like check, changes, status, and handoff keep the workflow lightweight.
Minimal setup
Slack, GitHub, and a scoped read-only AWS role are enough for the first useful workflow.
Change history beside the signal.
Context connects production symptoms to recent change history.
What-changed timeline
Recent code, deploy, GitHub Actions, CloudTrail, and AWS changes in one source-linked view.
GitHub deploy context
PRs, releases, GitHub Actions runs, deployments, and commit SHAs.
Operational status, not raw noise.
Context separates the human view from low-level technical health.
Operational status
Clear state for work that is unknown, investigating, degraded, recovering, stable, resolved, or blocked.
Technical health snapshot
Alarms, logs, service health, ECS, Lambda, ALB, RDS, and infrastructure signals.
Clean handoffs for the next responder.
The answer is source-linked, verifiable, and ready for the next responder.
Source-linked summaries
Every finding points back to the system of record.
Handoff summaries
Turn noisy channels and threads into concise summaries for late joiners and shift changes.
Coverage and limitations
The briefing names what was checked, what was found, and which sources were unavailable.
Read-only investigation
Gather evidence without giving Context permission to make production changes.
Works with the tools already in the workflow.
The first integrations focus on AWS, GitHub, and Slack, then expand based on early customer demand.
Operational evidence
CloudWatch alarms, CloudWatch Logs Insights, CloudTrail events, ECS, Lambda, ALB target health, RDS, and CloudFormation events.
Change and deploy history
PRs, commits, releases, GitHub Actions runs, deployments, and commit SHAs connected to the incident window.
Operational workflow
Slack-native requests, incident-channel context, handoff summaries, and source-linked updates for the team.
Future integrations may include Datadog, Grafana, PagerDuty, Sentry, Linear, and other tools based on early customer demand.
Read-only by design.
Context is built for investigation, not production control. It can summarize and link to evidence, but it does not roll back deploys, restart services, or change AWS resources.
Scoped and read-only
- Read-only AWS access
- Scoped permissions
- No secret access required for core workflows
- Clear limitations when a source is unavailable
Engineers stay responsible
- No auto-remediation
- No rollback or restart workflows
- No production write permissions
- Engineers verify before acting
Minimal by default
- No telemetry ingestion by default
- Minimal data retention
- Source links for every finding
- Audit trail of investigation activity
Why Context?
Dashboards show symptoms. Incident tools coordinate people. Context helps with the first investigation pass: gathering the facts engineers need before they decide what to do next.
Tool
What it does well
Where Context helps
CloudWatch
Shows AWS metrics, alarms, and logs.
Connects AWS signals to deploys, GitHub changes, and Slack context.
Datadog / New Relic
Stores and visualizes telemetry across systems.
Summarizes what changed and where to look without replacing observability.
Grafana
Turns metrics and logs into dashboards.
Gathers dashboard-adjacent evidence and explains the first investigation path.
PagerDuty
Routes alerts and on-call notifications.
Helps the paged engineer understand why they were paged.
incident.io / Rootly / FireHydrant
Coordinates incidents, roles, timelines, and process.
Adds operational evidence and suggested next checks inside Slack.
Slack workflows
Standardizes channel creation and responder coordination.
Posts source-linked production context into the workflow.
Runbooks
Document known procedures and expected checks.
Finds current evidence for the specific service, alert, and time window.
Custom scripts
Automate narrow checks for known systems.
Adds a reusable Slack-native context layer across common production questions.
Built for lean engineering teams.
Context is designed for teams that need better production context without adopting another heavy platform.
SaaS teams with 5-50 engineers
- AWS + GitHub + Slack teams
- Teams with frequent deploys
- Teams without a mature internal SRE platform
- Teams with recurring "what changed?" investigations
- Teams where production knowledge is scattered
Production-facing engineers
- Backend engineers
- On-call engineers
- DevOps and platform engineers
- SREs and engineering leads
Teams looking for something else
- Autonomous remediation
- A full observability replacement
- Teams not using Slack
- Teams not using AWS or GitHub
- Heavy enterprise procurement before a lightweight prototype
Simple pricing.
Pricing is intentionally simple while early teams help shape packaging and integration depth.
$19/month
For founder-engineers and solo operators.
- 1 Slack workspace
- 1 AWS account
- 1 GitHub connection
- Manual investigations
- Basic source-linked summaries
$49-$99/month
Recommended for small engineering teams.
- Slack-native investigations
- AWS read-only investigation
- GitHub deploy/change lookup
- What-changed timeline
- Handoff summaries
- Source-linked evidence
- Basic team configuration
$199-$499/month
For teams with multiple services, environments, or responders.
- Multiple services
- Multiple AWS accounts/environments
- Advanced investigation limits
- Audit logs
- Configurable retention
- Priority support
- Additional integrations as available
Early access teams can influence final packaging, limits, and supported workflows.
Early access
Join early access.
We are opening Context to engineering teams that regularly debug production and want a faster way to collect the first layer of operational evidence.
- AWS, GitHub, and Slack are part of your workflow.
- Production questions still require checking multiple tools.
- "What changed?" comes up often during debugging.
- Slack is where operational work is coordinated.
- Source-linked summaries matter more than autonomous remediation.
- A read-only prototype fits your current risk tolerance.
Questions engineers ask.
Clear boundaries for teams evaluating Context against tools they already use.
Does Context replace observability tools?
No. Datadog, Grafana, CloudWatch, and New Relic remain the systems of record for telemetry. Context brings relevant evidence from those workflows into Slack so engineers can orient faster.
Does Context replace incident management?
No. PagerDuty, incident.io, Rootly, and FireHydrant coordinate people and process. Context focuses on operational evidence: what changed, what looks unhealthy, and where to inspect next.
Is Context only for incidents?
No. Incidents are the first wedge, but the same context is useful for on-call support, deploy debugging, support escalations, handoffs, and service lookup.
Does Context make production changes?
No. Context is read-only by design. It does not roll back deploys, restart services, change AWS resources, or execute remediation steps.
What access does Context need?
Context needs scoped read-only access to the systems a team wants covered, starting with Slack, GitHub, and selected AWS services.
What happens when evidence is missing?
The response names the sources that were unavailable or not connected, so engineers know where the briefing is incomplete.
Does Context store logs?
Not by default. Context is designed to query existing systems during an investigation and link back to original evidence instead of becoming another telemetry store.
Can engineers verify the findings?
Yes. Source links point responders back to AWS, GitHub, Slack, or other connected systems so they can inspect the underlying evidence.
Is Context an AI SRE?
No. Context is an operational context assistant. It summarizes evidence and suggests next checks, but engineers remain responsible for diagnosis and remediation.
Who is Context for?
Context is for small and mid-sized engineering teams running production systems, especially SaaS teams using AWS, GitHub, and Slack.
Which integrations come first?
The first version focuses on Slack, AWS, and GitHub. Datadog, Grafana, PagerDuty, Sentry, Linear, and other tools may be prioritized based on early customer demand.
How is Context different from a generic chatbot?
Context is narrow and operational. It works from scoped production evidence, source links, and Slack-native workflows instead of trying to answer every engineering question.
Context
Bring production context back into the channel.
Context helps teams understand what changed, what looks unhealthy, and where to look next using read-only evidence from AWS, GitHub, deploys, logs, alerts, and Slack.